[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 #9 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #8)
> I think above and this is a succinct description of Stas's intended use
> case: having double mappings for solibs allows sharing data between the host
> and a VM with only address translation at the VM boundary, instead of
> address translation on every memory access inside the VM. Solutions exist
> for heap memory and stack memory, leaving primarily the .data/.bss memory
> allocated as part of an solib. (Correct me if I'm mistaken of course.)

That's correct.


> The proposed la_premap and la_premap_dlmem (part of the dlmem() patch)
> collectively "solve" this problem by granting LD_AUDIT some limited control
> over the object (segment) mapping process. My first impression from reading
> the test cases, they seem a bit too specific to this use case. IMHO they are
> also out-of-scope for LD_AUDIT: LD_AUDIT works at the level of symbols and
> objects, both generic across OSs and even binary formats (ELF + DLL),
> whereas la_premap* expose an implementation detail of the dynamic linker.

What exactly implementation detail?
Its just "here's the length I need to
map for solib. if you want, give me a
buffer and/or fd for it".
To me its quite similar to "here's the
name of the solib. if you want, give
me a different one to use".


> Most importantly, we do not yet deeply understand the implications exposing
> these callbacks can have, security or otherwise.

Any explanation why there can be any
security concerns here?


> An alternative solution I brought up in the prior discussion is "wrapping"
> the mmap syscall. In general, any Linux syscall can be wrapped using seccomp
> (e.g. via libseccomp [1]) or more recently with syscall user dispatch [2].
> With the wrapper in place, every mmap would be replicated in the VM memory
> window and update a table used for address translation. Some behavior
> changes would be needed to appropriately implement MAP_ANONYMOUS and
> MAP_FIXED, but neither seem particularly problematic.

I don't understand what you mean.
Besides the fact that you want to describe
something very specific to particular libc
(intercepting the particular mmap call, knowing
how the particular dynamic loader works),
you haven't written the detailed scheme of
what you propose.
You were referring (in another thread) to
trapping only the first mmap() call done by
dynamic loader, IIRC. How can that lead to
a solution of having 2 identical mappings,
is essentially unclear. At best it can solve
the problem of specifying the reloc address,
by the cost of depending on a particular impl
of particular libc, forgetting about any
portability to other libces.
So please detail your proposal.


> If this well-understood approach solves the problem, IMHO there isn't much
> point in arguing this RFE further.

It doesn't solve anything (except probably
the reloc address), and the statements like
this, together with the statement that my
patch breaks your use-case or raises a
security concerns, only suggests that you
want to down-play any contributions that you
review.
In fact, since you never ever said a single
word about how any of the multiple proposals
(including DT_AUDIT for dlopen()) can be
improved, I am quite sure its the case.
I hope we can get more constructive.


> (In reply to Stas Sergeev from comment
> You're right, neglected .bss when suggesting this idea. This would not be an
> issue when using an mmap wrapper however, as the region is simply mapped
> with MAP_ANONYMOUS.

I don't understand how this would not be
an issue, please clarify. Region mapped
with MAP_ANONYMOUS cannot be shared with VM.


> (In reply to Stas Sergeev from comment
> To clarify here, the "first" call to mmap() is the one without MAP_FIXED,
> and is used to allocate the pages that will later be overwritten by
> MAP_FIXED. Threads should not become a problem here, just check the flags.

Why any other thread can't do unrelated
mmap() without MAP_FIXED?

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