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

[Farid Zakaria <fmzakari@ucsc.edu>]

Thanks for the advice.

I'm now looking at the following two options (seeing if they work):
1. I see that an auxiliary vector is the FD or the name of the file
given to dynlink.
Can I mmap this file again in it's entirety and read the section I care about?

2. Try to create a segment that maps to the sections I care about such
that they are loaded.
(Try to apply some heuristic to then identify it)

Early attempts at (1) have the mmap failing -- i need to debug further.


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