[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0

[mintsuki at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31795

--- Comment #41 from mintsuki <mintsuki at protonmail dot com> ---
(In reply to Adhemerval Zanella from comment #39)
> (In reply to Fangrui Song from comment #37)
> > I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
> > should not be needed.
> > 
> > From https://sourceware.org/pipermail/binutils/2013-December/083381.html
> > 
> > > Linker sets e_type in ELF header to ET_DYN for -pie -Ttext-segment=0xXXX.
> > > When I added -Ttext-segment=0xXXX, one goal was to load
> > > small model executable above 4GB on Linux/x86-64, which
> > > was done with -pie -Ttext-segment=0xXXX.  But -pie sets
> > > e_type in ELF header to ET_DYN and kernel may ignore
> > > p_vaddr in ELF header to load ET_DYN binary at a random
> > > address.  This patch changes ld to set e_type in ELF header
> > > to ET_EXEC if the first PT_LOAD segment has non-zero
> > > p_vaddr.  If this is unacceptable as generic ELF change,
> > > I can make it specific to x86.
> > 
> > Was the intention for the following command to load the text segment at an
> > address >= 0x600000000000 ?
> > 
> > ```
> > % cat a.c
> > #include <stdio.h>
> > int main() { printf("%p\n", main); }
> > % gcc -pie -Wl,-no-pie a.c -fuse-ld=bfd
> > -Wl,--no-relax,-Ttext-segment=0x600000000000 -o a
> > % ./a
> > 0x600000001139
> > % ./a
> > 0x600000001139  # no ASLR
> > ```
> > 
> > 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). 

My understanding is that the PT_LOAD PHDR addresses could be slid, as long as
they are slid above the specified address. The fact that the first PT_LOAD PHDR
is 0 or not should be irrelevant. It makes no sense for it to be relevant, let
alone for it to dictate the ELF type to be ET_EXEC.

This is how Limine behaves, and how I interpret the ELF format.

> 
> 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.
> 
> > 
> > I added `--no-pie` to GNU ld in 2021:
> > https://sourceware.org/cgit/binutils-gdb/commit/
> > ?id=e8f6c2a5bab10b039a12b69a30a8248c91161e11 , with which we can do the
> > following instead. (GNU ld also needs `--no-relax` while lld doesn't).
> > 
> > ```
> > % gcc -pie a.c -fuse-ld=bfd
> > -Wl,--no-pie,--no-relax,-Ttext-segment=0x600000000000 -o a
> > % ./a
> > 0x600000001139
> > % ./a
> > 0x600000001139
> > ```

-- 
You are receiving this mail because:
You are on the CC list for the bug.