Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 8 May 2022 09:54:44 -0400
From: Rich Felker <>
To: Markus Wichmann <>
Cc:, Pablo Galindo Salgado <>
Subject: Re: Why the entries in the dynamic section are not always

On Sun, May 08, 2022 at 01:39:10PM +0200, Markus Wichmann wrote:
> On Sun, May 08, 2022 at 08:48:29AM +0100, Pablo Galindo Salgado wrote:
> > Why is this happening?
> The easy question first: This is happening because glibc finds some
> value in writing the actual addresses into the dynamic section, and musl
> does not. All of the addresses given in the dynamic section must
> necessarily be offsets into the library itself (rather, the run-time map
> of the library), so anyone who knows the base address of the library can
> interpret these values, anyway.

That's basically it. musl does not do this mainly because it's not
possible in general -- on some archs _DYNAMIC is in read-only memory
-- and we generally avoid arch-specific behavior in the dynamic
linker. The only part of _DYNAMIC we modify, on archs where it's
allowed, is DT_DEBUG, because that's a (nasty, should be replaced)
interface with debuggers to let them find things.

> See, you are accessing an implementation detail here. I am not aware of
> any documentation of dl_iterate_phdr() which says whether the dynamic
> section is relocated or not. Which leads directly to:

It's not so much in the scope of dl_iterate_phdr, but in the runtime
contents of ELF data structures. There are specs on *some* of that,
but they are not among the list of standards musl purports to conform
to (and for example some things like handling of RPATH/RUNPATH
intentionally differ from legacy behaviors here).

> > How can one programmatically know when the linker is
> > going to place here offsets or full
> > relocated addresses?
> In general, you cannot. You could reconstruct the length of the library
> mapping from the LOAD headers, then heuristically assume that any value
> below that is an offset, and any value above it probably a pointer.
> Doesn't help you far, though, since you also need the base address.
> Though I suppose you could assume that the start of the page the PHDRs
> start on is likely the base of the library mapping.
> Also, the heuristic will fail for libraries mapped to a low address. In
> theory, all address space after the zero page is fair game, right? But
> libraries can take more space than that.
> And God help you if you ever run into an FDPIC architecture.
> It appears to me that whatever you are trying to do is not possible
> portibly on Linux at this time. Could you fill us in?

Indeed, this is probably either an XY problem with a simple portable
way to achieve whatever the underlying goal is, or a glorious hack
that's making a lot more assumptions about implementation internals
and not something you'd be able to rely on continuing to work in the
future, even if you got it working.


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.