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

[Farid Zakaria <fmzakari@ucsc.edu>]

For those reading the list, I ended up just opening the file with the
'app.name' and then mmap it.

```
int fd = open(app.name, O_RDONLY);
if (fd < 0) {
        dprintf(2, "failed to open");
        _exit(1);
}

struct stat st;
fstat(fd, &st);
const ElfW(Ehdr)* ehdr = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (ehdr == MAP_FAILED) {
      dprintf(2, "failed to mmap");
      _exit(1);
    }

if (!ehdr || memcmp(ehdr->e_ident, ELFMAG, SELFMAG) != 0) {
   dprintf(2, "Not a valid elf file\n");
   _exit(1);
}

const ElfW(Shdr)* section_header = find_section_by_name(ehdr, ".some-section");
if (section_header == NULL) {
   dprintf(2, "Cannot find .sqlelf section\n");
   _exit(1);
}
```

On Mon, Oct 16, 2023 at 3:04 PM Rich Felker <dalias@libc.org> wrote:
>
> 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