https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #66 from mintsuki <mintsuki at protonmail dot com> --- (In reply to Fangrui Song from comment #65) > > > Changing ET_DYN to ET_EXEC fulfills the address requirement but disables > > > ASLR. > > > Is it intentional? > > > > That's my understanding of reading the -Ttext-segment documentation. The > > question is whether we relax the semantic to have it as a minimum address > > or define it as the expected address (thus disabling ASLR as a > > consequence). > > > > I don't have a strong opinion, but currently, Linux only enforces the > > former (I think it is the main reason this makes some sense) so we will > > need to discuss with kernel developers the expected semantics. > > If there is a strong need for the address requirement (>=p_vaddr), Linux > kernel and glibc have the capability to implement it. > However, this alone does not justify keeping the ld hack that sets ET_EXEC > for -pie -Ttext-segment=$non_zero. > > > -Ttext-segment=0x600000000000 should create a binary which is guaranteed to > > be > > loaded at 0x600000000000. > > -Ttext-segment sets the address of the first byte of the text segment, which > likely influences the p_vaddr member of a PT_LOAD segment. > When e_type is ET_EXEC, this address is also the virtual address of the > first memory area. > However, if e_type is ET_DYN, there's no guarantee of this address, and > fulfilling this request is left to the discretion of the loaders. > > Since ld offers the -no-pie flag, there's no need for a workaround to make > -pie behave similarly. > (In addition, DF_1_PIE with ET_EXEC is very odd.) Indeed. This is not what lld does, at all. Also the statement that PIE executables with non-0 load addresses would misbehave if relocated is also something that I cannot wrap my head around, especially since I have been relocating these for years without issues. Those generated by lld, gold, and bfd, the former 2 of which have absolutely no issue generating a PIE with non-0 load address. Also I will change the title of the bug report from static PIE to PIE, because the PIE having or not having dynamically linked libraries is irrelevant to the issue at hand. > > If a user desires both address>=0x600000000000 && ASLR, this could be > achieved if ET_DYN is used and loaders satisfy the address requirement. > However, retaining the ET_EXEC hack in ld would prevent the fulfillment of > this goal. > > > PIE is the only way to create a small mode executable loaded at > > 0x600000000000. > > This is an oversimplification. > > The -mcmodel= flag imposes specific code generation restrictions that allow > relocatable files to be used in certain address space layouts after linking. > While it's (almost) a sufficient condition, it's not a necessary one. > > Achieving high-address functionality doesn't necessitate -mcmodel=large. For > instance, you can use PIC symbol addressing (combining -mcmodel=small -fpie > with non-preemptible symbols) to achieve the same result. > If your code is larger than 2GiB, you can even use range extension thunks. > > https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models#x86- > 64-code-models > > Similarly, for a function call, we no longer assume that the address of > the function or its PLT entry is within the ±2GiB range from the program > counter, so call callee cannot be used. > > Actually, call callee can still be used if we implement range extension > thunks in the linker, unfortunately GCC/GNU ld did not pursue this direction. > > > There are 2 issues with -mcmodel=large: > > > > 1. Since there are no -mcmodel=large run-time libraries, you can't use > > -mcmodel=large > > to create any meaningful binaries. > > 2. -mcmodel=large performance is much slower. > > True. (1) is an ecosystem issue with -mcmodel=large. > However, this point is unrelated to the ld ET_EXEC hack. > > > I think BFD can use the emulation (-m) option for this, since, for > > instance, gcc will pass -maarch64linux for aarch64-linux-gnu. > > I don't think this is necessary. > > `-pie -Wl,-no-pie` works today (lld doesn't even need `--no-relax`). > Therefore, there isn't a strong argument retaining the ET_EXEC hack. > > % gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd > -Wl,--no-relax,-Ttext-segment=0x600000000000 -o a > % ./a > 0x600000001139 > % ./a > 0x600000001139 # no ASLR -- You are receiving this mail because: You are on the CC list for the bug.
