Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Oct 2023 23:53:07 +0200
From: Szabolcs Nagy <>
To: Rich Felker <>
Cc: Farid Zakaria <>,
Subject: Re: Getting access to section data during dynlink.c

* Rich Felker <> [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.


#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)

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.