Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Jun 2017 11:01:18 -0400
From: Rich Felker <>
Subject: Re: a possible need for MAP_FIXED in ldso/dynlink.c ?

On Sat, Jun 10, 2017 at 04:32:25PM +0200, wrote:
> On Sat, Jun 10, 2017 at 08:26:10AM -0400, Rich Felker wrote:
> > On Sat, Jun 10, 2017 at 12:51:51PM +0200, wrote:
> > > Adding the MAP_FIXED flag, both conditionally or not, seems to work
> > > around the particular problem but I am unsure about all its implications
> > > and consequences, among others under the current Linux implementation
> > > of the Lunux ABI.
> > Use of MAP_FIXED with a memory range you don't already own is an
> > invalid and unsafe operation. You may end up mapping over top of
> > yourself, even.
> But the latter should be possible to avoid as long as we know where
> ourself is located (?) Or do we?

Not easily. And you don't know that something else isn't mapped there,
like perhaps a data page needed by the vdso or some other
kernel-mapped code (perhaps sigreturn trampolines). The only way to
know that would be nasty hacks like parsing /proc/self/maps. And the
code that does the mapping is not restricted to running before program
startup. At any later time, any check is subject to TOCTOU races. Use
of MAP_FIXED is simply not safe/not valid except when the caller
already "owns" the address range to be mapped. It's not sufficient to
require that "nothing else be using it"; you really need "I own it and
I authorize it to be replaced with something else".

> > Implementations should honor the requested address
> > passed to mmap and only fail to provide it if it's already in use.
> I did not see this statement anywhere in the mmap() documentation
> (and even if I am misinformed, you say "should" not "must").
> E.g.
> says
> "When MAP_FIXED is not set, the implementation uses addr in an
> implementation-defined manner to arrive at pa."

Indeed, not all implementations will define this in a way that admits
mapping programs at a hard-coded address, but then they're not
suitable for dynamic loading of non-PIE programs.

BTW one reason the standard can't really formally define loading at a
requested address is that pointers that don't point to an existing
object or null are not even a valid concept in the C language.

> > applications that don't have a reason for requesting a
> > particular address should, and do, pass 0 as the request.
> Notwithstanding this, I find the API very unclear about how to
> safely check whether the use of a certain address range is impossible
> or just differs from the particular "implementation-defined manner"
> to derive the returned value.
> Does this mean that musl can not implement the explicit dynamic loader
> with mere Posix mmap(), only with the "more tightly specified Linux mmap()"?

Yes, I think that's accurate. Of course you can use PIE binaries and
then you don't have to care about it, since they can be loaded at any


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.