Re: [RFC][PATCH v1 0/5] Proof-of-Concept implementation of RTLD_SHARED for dlmopen

["Vivek Das Mohapatra" <vivek@collabora.com>]

> 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.