[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH4OOv7trtsu5tnV03Z0Ya0VXDBaLbR9iFwVpiOMKXUtp8QjYQ@mail.gmail.com>
Date: Mon, 16 Oct 2023 14:09:06 -0700
From: Farid Zakaria <fmzakari@...c.edu>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Getting access to section data during dynlink.c
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
