[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170610150118.GR1627@brightrain.aerifal.cx>
Date: Sat, 10 Jun 2017 11:01:18 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: a possible need for MAP_FIXED in ldso/dynlink.c ?
On Sat, Jun 10, 2017 at 04:32:25PM +0200, u-uy74@...ey.se wrote:
> On Sat, Jun 10, 2017 at 08:26:10AM -0400, Rich Felker wrote:
> > On Sat, Jun 10, 2017 at 12:51:51PM +0200, u-uy74@...ey.se 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. http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
> 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
address.
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.
