This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH v1 0/5] Proof-of-Concept implementation of RTLD_SHARED for dlmopen
I think the basic design question is "Where does the namespace split exist?"
If you say the namespace split is below ld.so, then the inner namespace must
load it's own loader, and handle everything on it's own. This is possible,
but means that outer threads *must never* call into the inner namespace,
and that limits the usefullness to a kind of client<->server model where
shared memory must be used across the namespaces. Your proposal in no way
limits the choice of eventually having this kind of model.
Right, I've not touched anything down at that level at all.
Astute readers might argue that if the inner and outer ld.so's agreed on
an API/ABI then the thread *could* cross the boundary and retain a coherent
TLS storage. Florian Weimer has been discussing something like this, which
might let users replace ld.so with their own instrumented version to support
broader use case models for debugging or more complex auditing than LD_AUDIT
supports.
Indeed - although I suspect a _lot_ of careful thought about what does
and doesn't have to be agreed on would need to be done - even with the
same libc* mapped into each namespace separately you can get deadlocks
(like the bug that triggered all this).
*where libc = the core group of glibc DSOs
It's clear to me that dlmopen is *most* useful when threads can cross the
boundary of the dlmopen call, and in order to do that the thread and all
the associated thread-local data must be coherent between the outer
namespace and the inner namespace. Here we are proposing that dlmopen is
for all shared libraries *above* glibc. This model also does not limit
making the split lower at a later date and using a different flag. Having
the namespace split exist just beyond glibc makes the most sense for the
average user.
Agreed.
Note that LD_AUDIT actually implements a third split position, just above
ld.so, and so it uses the same dynamic loader, but new versions of all
the other libraries.
I had noticed this, and my implementation is pretty much that mechanism
on [a small dose of] steroids.
So your proposal is really to put the split at just above glibc, or to
be more precision, above ld.so/libc.so.6/libpthread.so.0, which form a
coherent group that implements threads.
If I have that wrong, please correct me.
That all sounds right.
Further things I should mention:
- I was wondering if anything other than the core cluster mentioned
above needed to be shared.
- On a semi related note: The runtime-isolation work that triggered
the original project needs to capture the whole of the libc cluster:
would you be averse to there being some sort of mechanism that would
allow a program to determine the list of .so files that constituted
the GLIBC installation? Could be API returning a list of sonames, or
a canonical manifest file would probably also do.