[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH4OOv5vSsUEBYAkyqOvCgLcTvSSQ-UL3p5BX1b5rf-NZaCOaA@mail.gmail.com>
Date: Mon, 16 Oct 2023 14:16:23 -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
Okay -- the following works (see below).
At first I was trying with AT_EXECFD but looks like it's not set for
ELF -- instead I used the app.name variable.
```
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, ".watever");
if (section_header == NULL) {
dprintf(2, "Cannot find .sqlelf section\n");
_exit(1);
}
```
On Mon, Oct 16, 2023 at 2:09 PM Farid Zakaria <fmzakari@...c.edu> wrote:
>
> 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.
