Re: [musl] Getting access to section data during dynlink.c

[Rich Felker <dalias@libc.org>]

On Mon, Oct 16, 2023 at 11:53:07PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2023-10-16 10:26:04 -0400]:
> > On Sun, Oct 15, 2023 at 06:06:48PM -0700, Farid Zakaria wrote:
> > > Hi!
> > > 
> > > I'd like to read some section data during dynlink.c
> > > Does anyone have any good suggestions on the best way to do so?
> > > I believe most ELF files ask for the load to start from the start of the
> > > ELF file.
> > > 
> > > I see in dynlink.c the kernel sends AT_PHDR as an auxiliary vector --
> > > Should I try applying a fixed offset from it to get to the start of the
> > > ehdr ?
> > > 
> > > Any advice is appreciated.
> > > 
> > > Please include me in the CC for the reply.
> > > I can't recall if I've subscribed.
> > 
> > Neither the Ehdrs nor sections are "loadable" parts of an executable
> > ELF file. They may happen to be present in the mapped pages due to
> > page granularity of mappings, but that doesn't mean they're guaranteed
> > to be there; the Ehdrs are for the program loader's use, and the
> > sections are for the use of linker (non-dynamic), debugger, etc.
> > 
> > In musl we use Ehdrs in a couple places: the dynamic linker finds its
> > own program headers via assuming they're mapped, but this is rather
> > reasonable since we built it and it's either going to always-succeed
> > or always-fail and get caught before deployment if that build-time
> > assumption somehow isn't met. It's not contingent on properties of a
> > program encountered at runtime. We also use Ehdrs when loading a
> > program (invoking ldso as a command) or shared library, but in that
> > case we are the loaded and have access to them via the file being
> > loaded.
> > 
> > Depending on what you want to do, and whether you just need to be
> > compatible with your own binaries or arbitrary ones, it may suffice to
> > do some sort of hack like rounding down from the program header
> > address to the start of the page and hoping the Ehdrs live there. But
> > it might make sense to look for other ways to do what you're trying to
> > do, without needing to access non-runtime data structures.
> 
> note that (not too old) bfd ld and lld defines a hidden linker symbol
> __ehdr_start that at runtime resolves to where the ehdr is.
> 
> example:
> 
> #include <elf.h>
> #include <stdio.h>
> 
> __attribute__((visibility("hidden"), weak)) extern char __ehdr_start[];
> 
> int main()
> {
> 	if (__ehdr_start) {
> 		Elf64_Ehdr *ehdr = (void *)__ehdr_start;
> 		printf("ehdr %p\n", ehdr);
> 		Elf64_Phdr *phdr = (void *)(__ehdr_start + ehdr->e_phoff);
> 		printf("phdr %p\n", phdr);
> 	} else
> 		printf("__ehdr_start is undefined\n");
> 
> 	// to compare against the actual mappings
> 	char buf[9999];
> 	FILE *f = fopen("/proc/self/maps","r");
> 	size_t n = fread(buf, 1, sizeof buf, f);
> 	fwrite(buf, 1, n, stdout);
> }
> 
> this should work for 64bit elf exe if ehdr is mapped into memory.
> 
> if you want link time error on an old linker instead of 0 __ehdr_start,
> then just drop "weak" and the runtime check. (the code as written assumes
> ehdr is not at exact 0 address, which is guaranteed by usual linux setups)

Interesting -- perhaps we should find a way to use this in ldso to
find its own ehdr.

Rich