https://sourceware.org/bugzilla/show_bug.cgi?id=30907
--- Comment #3 from nilus <ocs-bot at opencloudos dot tech> --- (In reply to Nick Clifton from comment #2) Hi, Nick Thanks for your patient reply, I still have some confusion here. > (In reply to nilus from comment #0) > Hi Nilus, > > > When we use binutils 2.39 (or higher, like 2.40) to compile files on > > aarch64, we find that the newly compiled binary file size is 128K larger > > than the binary file compiled using binutils 2.38. > > Are you concerned about disk space usage or memory usage ? > > The larger version will probably not be occupying a lot more disk space, > since the unused sections of the file will not be allocated to real disk > space. Likewise > the altered layout of the larger file will only matter to the runtime if > they cause extra pages to be allocated. Many filesystems support sparse files(like ext4, xfs, etc.), But when I use `du -h` to get the size of binary, I saw it acutally occupied extra 128KiB disk space, beacuse the binary is not be built or regarded as a sparse file, which makes it bigger than before. I also compared fc38 aarch64 docker image size and fc39 aarch64 docker image size after `docker pull`, The latter is half larger than the former because many binaries are larger 128K than before. > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x0000000000003448 0x0000000000003448 R E 0x10000 > > LOAD 0x000000000000fc60 0x000000000001fc60 0x000000000001fc60 > > 0x00000000000003a8 0x00000000000003b0 RW 0x10000 > > > Segment Sections... > > 00 .note.gnu.property .note.gnu.build-id .gnu.hash .dynsym .dynstr > > .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini > > .rodata .eh_frame_hdr .eh_frame > > 01 .init_array .fini_array .dynamic .got .data .bss > > vs... > > > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 > > 0x0000000000001168 0x0000000000001168 R 0x10000 > > LOAD 0x0000000000010000 0x0000000000010000 0x0000000000010000 > > 0x0000000000001dc0 0x0000000000001dc0 R E 0x10000 > > LOAD 0x0000000000020000 0x0000000000020000 0x0000000000020000 > > 0x0000000000000a8c 0x0000000000000a8c R 0x10000 > > LOAD 0x000000000002fc30 0x000000000003fc30 0x000000000003fc30 > > 0x00000000000003d8 0x00000000000003e0 RW 0x10000 > > > Segment Sections... > > 00 .note.gnu.property .note.gnu.build-id .gnu.hash .dynsym .dynstr > > .gnu.version .gnu.version_r .rela.dyn .rela.plt > > 01 .init .plt .text .fini > > 02 .rodata .eh_frame_hdr .eh_frame > > 03 .init_array .fini_array .dynamic .got .data .bss > > This is a security issue. Notice how in the first version you have a > segment with Execute permission that contains lots of sections that do not > need the execution ability. In the second version these sections are > relegated to their own, just read only, segment. Likewise data is > completely separated from code, so the .rodata section for example no longer > shares a segment with .text. > I agree that this is a security issue, Separating data and code is a best practice. But I wonder that why the alignment is not the kernel PAGESIZE(I set PAGE_SIZE to 4096 when compiling, but the alignment is still 65535)? Whether can we make ELF_MAXPAGESIZE in elf-*.c match the kernel PAGE_SIZE? regards Nilus -- You are receiving this mail because: You are on the CC list for the bug.
