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

[Carlos O'Donell <carlos at redhat dot com>]

On 05/16/2018 01:11 PM, Vivek Das Mohapatra wrote:
> As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=22745
> dlmopen requires a mechanism for [optionally] sharing some objects
> between more than one namespace.
> 
> The following patchset attempts an implementation for this: If an object
> is loaded with the new RTLD_SHARED flag we instead ensure that a "master"
> copy exists (and is flagged as no-delete) in the main namespace and a
> thin wrapper or clone is placed in the target namespace.
> 
> I have attached the test program(s) I am using to the bug above.
> 
> It is not intended as a final implementation but I wanted to check
> that the basic approach is acceptable/workable.
> 
> If it is, then I plan to extend the patchset as follows:
> 
>  - dlmopen will implicitly apply RTLD_SHARED to the libc/libpthread group
>  - The user will be able to request that this sharing _not_ occur
>    by passing a different flag to dlmopen (name TBD)
>  - LD_AUDIT paths will not apply this implict sharing rule, so audit libraries
>    will continue to be completely isolated.

Thank you for working through this!

> If it isn't, then I guess it's back to the drawing board (but reasons why
> it isn't acceptable/workable would be appreciated so I can figure out how
> to do it right).

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.

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.

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.

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.

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.

> Vivek Das Mohapatra (5):
>   bits/dlfcn.h: Declare and describe the dlmopen RTLD_SHARED flag
>   include/link.h: Update the link_map struct to allow clones
>   elf/dl-object.c: Implement a helper function to clone link_map entries
>   elf/dl-load.c, elf-dl-open.c: Implement RTLD_SHARED dlmopen cloning
>   elf/dl-fini.c: Handle cloned link_map entries in the shutdown path
> 
>  bits/dlfcn.h               |  7 +++++
>  elf/dl-fini.c              | 50 ++++++++++++++++++++++++++++++
>  elf/dl-load.c              | 34 ++++++++++++++++++++
>  elf/dl-object.c            | 77 ++++++++++++++++++++++++++++++++++++++++++++++
>  elf/dl-open.c              | 31 +++++++++++++++++--
>  include/link.h             |  6 ++--
>  sysdeps/generic/ldsodefs.h |  6 ++++
>  7 files changed, 207 insertions(+), 4 deletions(-)
> 


-- 
Cheers,
Carlos.