[Bug dynamic-link/30007] rfe: dlopen to specified address

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30007

--- Comment #16 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #15)
> As Adhemerval has already mentioned from the very start of this RFE (comment
> #1):
> > Any GNU extension requires a specific usercase that can't be easily accomplished with current API.

"easily" is quite important here.
Even if your syscall interception approach
could work (which I think is not the case),
it doesn't fall into an "easy" category.
To me, having a good API is also important.
Why dlmem() is not the one?
But lets deal with the question if your trick
works at all first.


> Thus, the first priority for this RFE should be to establish this use case
> and express the failings of the current technology. A proposed patch series
> is difficult to review

Even when I split them into 13 nearly trivial
patches? Then what else can I do to have it
easy for a review?


> and near-impossible to merge without reaching some
> kind of consensus on these two points. Until this occurs, all but the most
> preliminary work on a patch is a waste of many people's time and patience,
> including yours as the author.

Not necessarily: after all I can try to use
the private glibc build for my project. But
of course its a PITA so I prefer to not having
to do that.


> It would be very constructive if you could investigate my proposed solution
> as detailed below, and precisely express what the insurmountable problems
> with it are. :D

I always do. :)


> Namely, establishing the use case in clear terms and expressing why the
> alternative technology of "dlopenfd()" + memfd_create() fails to meet the
> use case.

I thought we are already passed that point,
and instead are discussing why mmap() intercept
fails? dlopenfd()+memfd doesn't give even the
possibility of specifying the reloc address,
and that's a very minimal, insufficient requirement.


> These callbacks allow ASLR to be disabled completely in userspace. If a
> poorly implemented auditor causes dynamic library loading to become
> extremely predictable, an attacker may find a way to steal cryptographic
> secrets stored in the bss segment. High-security container runtimes can't
> easily protect against this ASLR-loss since the kernel is not involved.
> 
> Is there a *real* security risk here? No idea, I have no clue if disabling
> ASLR in non-setuid applications is really a problem.

I think its quite similar to allowing MMAP_FIXED,
which is allowed. One can already map his secret
data always to the specific location, so there was
nothing new. But in any case, LD_AUDIT bits are
dropped from my patch.


> MAP_ANONYMOUS doesn't provide an fd to "mirror" the pages through, so the
> wrapper will need to provide one. This can easily be a private memory-backed
> file (e.g. memfd_create). Allocate some pages from this file before (1), and
> use that for the fd and offset in the remaining steps.

I still don't understand that part.
You propose to intercept first mmap.
In the current impl its a file-backed
private mmap that spans past the end
of the file. So basically it is 2 mmaps
in one: what goes beyond the file image,
is similar to anonymous.
So do you propose to split that mmap
into 2, mirror the file-backed part and
then mirror the anonymous part with the
memfd_create, correct?
But the problem is that first mmap
actually only establishes the map address.
Subsequent mmaps re-arrange the segments,
over-mapping that space. So where you
initially thought is an anonymous space,
will be a file-based mapping, and vice-versa.
You can clearly see that from my patch 2.
It converts the first mmap into an
anonymous one (fully anonymous, not
file-backed past eof). So the first mmap
doesn't have the actual layout, and so
it can't establish any mirroring. It
just allocates the space, and gets later
over-mapped by the loader.
Does this clarify?


> That's the basic approach. This approach wraps mmap() while conforming to
> the Linux API, so it works for any segments that are mmap()'d. In GNU/Linux,
> solibs and .bss are included in that set.

The problem is that first mmap has no
idea where the .bss will be mapped.
Neither does he know where the code is
going to be mapped. The only reason its
not anonymous currently in glibc, is
because the first elf segment is supposed
to be in the beginning. But everything
else gets over-mapped.
I am not even sure why the first segment
should be at the beginning, does it
always have the vaddr==0? But so do the
comments in the present code suggest.


> Obviously this approach only works on Linux. Other OSs have their own
> syscalls and methods for intercepting them. I only know Linux, was there
> another OS you plan to support?

Not in the near future, maybe eventually.
But I still fail to see why would the one
want to do syscall interceptions instead
of adding the right API, even if such
interception could work (but it can't).

-- 
You are receiving this mail because:
You are on the CC list for the bug.