[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before

[ocs-bot at opencloudos dot tech]

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.