[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Nick Clifton changed: What|Removed |Added Last reconfirmed||2024-06-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #8 from Nick Clifton --- Hi Nilus, Hi Fanguri, I have checked in e8e10743f7b to add a --rosegment option the linker. This should address the size increase when -z separate-code is used. I am setting the state of this PR to 'waiting' as the patch is still brand new and there may well be problems with it that I have not anticipated. Cheers Nick PS. I have also committed 54904469f71 to fix some test case issues when the new option is enabled by default. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 --- Comment #7 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e8e10743f7b207b21a1efb0cc9e42487080db013 commit e8e10743f7b207b21a1efb0cc9e42487080db013 Author: Nick Clifton Date: Thu Jun 13 15:10:15 2024 +0100 Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. PR 30907 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26925 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 --- Comment #6 from Nick Clifton --- (In reply to Fangrui Song from comment #4) > Perhaps GNU ld can split `-z separate-code` into two options `--rosegment` > and `-z separate-code`? > I have some description at > https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-rosegment This should certainly be doable. Patches welcome. :-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 --- Comment #5 from Nick Clifton --- (In reply to nilus from comment #3) > 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? You are using the Fedora binutils, right ? That version of the binutils changes the default page size of 0x1, which is why you are seeing that value in your binaries. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #4 from Fangrui Song --- Perhaps GNU ld can split `-z separate-code` into two options `--rosegment` and `-z separate-code`? I have some description at https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-rosegment > Separating data and code is a best practice. Therefore lld defaults to --rosegment while it defauls to `-z noseparate-code` to avoid waste. File content at the boundary of R/RX can be double mapped, which technically can be used to find ROP gadgets. However, decreasing ROP gadgets there is pretty much a secure theatre. https://isopenbsdsecu.re/mitigations/rop_removal/ is somewhat related. > 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)? The protocol between the linke and the kernel is that a linked object file may run on systems with different page sizes. All page sizes not larger than MAXPAGESIZE (link-time decision) are supported. The model in practice does not build a different object file for each page size. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=30612, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28824, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24490 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 --- Comment #3 from nilus --- (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 0x 0x 0x > > 0x3448 0x3448 R E0x1 > > LOAD 0xfc60 0x0001fc60 0x0001fc60 > > 0x03a8 0x03b0 RW 0x1 > > > 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 0x 0x 0x > > 0x1168 0x1168 R 0x1 > > LOAD 0x0001 0x0001 0x0001 > > 0x1dc0 0x1dc0 R E0x1 > > LOAD 0x0002 0x0002 0x0002 > > 0x0a8c 0x0a8c R 0x1 > > LOAD 0x0002fc30 0x0003fc30 0x0003fc30 > > 0x03d8 0x03e0 RW 0x1 > > > 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.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- (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. > LOAD 0x 0x 0x > 0x3448 0x3448 R E0x1 > LOAD 0xfc60 0x0001fc60 0x0001fc60 > 0x03a8 0x03b0 RW 0x1 > 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 0x 0x 0x > 0x1168 0x1168 R 0x1 > LOAD 0x0001 0x0001 0x0001 > 0x1dc0 0x1dc0 R E0x1 > LOAD 0x0002 0x0002 0x0002 > 0x0a8c 0x0a8c R 0x1 > LOAD 0x0002fc30 0x0003fc30 0x0003fc30 > 0x03d8 0x03e0 RW 0x1 > 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. If you do not like this behaviour, you should be able to turn it off by linking with "-z,noseparate-code". Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 --- Comment #1 from nilus --- after git bisect between 2.38 and 2.39, I found the commit which introducted this LOAD segment change: commit f420c9c84eb53fea7da452eab8ae0bd855537859 Author: Alan Modra Date: Sun May 22 14:00:06 2022 +0930 bit-rot in target before_parse function Copy initialisation over from the elf.em before_parse. Commit ba951afb999 2022-05-03 changed behaviour on arm and score regarding exec stack. This patch restores the previous behaviour. * emultempl/aarch64elf.em (before_parse): Init separate_code, warn_execstack, no_warn_rwx_segments and default_execstack. * emultempl/armelf.em (before_parse): Likewise. * emultempl/scoreelf.em (before_parse): Likewise. * testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Return true for arm and nacl. ld/emultempl/aarch64elf.em | 4 ld/emultempl/armelf.em | 4 ld/emultempl/scoreelf.em| 4 ld/testsuite/ld-elf/elf.exp | 2 -- 4 files changed, 12 insertions(+), 2 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30907] ELF segment add extra 2 LOAD segments in aarch64, making binary bigger 128KiB than before
https://sourceware.org/bugzilla/show_bug.cgi?id=30907 nilus changed: What|Removed |Added Summary|ELF segment seperated into |ELF segment add extra 2 |4 LOAD in aarch64, making |LOAD segments in aarch64, |binary bigger 128KiB than |making binary bigger 128KiB |before | than before -- You are receiving this mail because: You are on the CC list for the bug.
