Re: dlmopen and variables in the dynamic loader

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

On 8/16/19 9:04 AM, Zack Weinberg wrote:
> On Fri, Aug 16, 2019 at 7:44 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> dlmopen carefully replicates the initial ld.so in all namespaces.
>> Unlike libc.so, ld.so is only loaded once.  This can be used to share
>> state across all namespaces.
> 
> Is it possible that we should change this, and load libc.so only once
> as well?  (And maybe also libpthread and libgcc_s?  I guess at that
> point we need to invent a DT_ONLY_LOAD_ME_ONCE tag...)

This is what Vivek Des Mohapatra's patches do with the proxy object
concept [1][2]. All of the C runtime implementation is shared and the
dlmopen isolation is only for objects loaded outside of the
implementation.

Even with a shared libc you will still have problems. Any executable
reference to data in libc.so.6 will create a COPY relocation in the
executable and the binding in the base namespace will reference the
.bss in the executable as the copy. Then when you load another
reference to the same data symbol in libc.so.6 it will reference the
copy in libc.so.6 instead (and so will all the other namespaces).
You will have at most 2 copies, the one in the binary, and the one
in the shared (proxied) libc.so.6.

For some semantics this may be OK, but if it's a global coordination
issue then it's not going to work.

Any reloction whose semantic is to forward a symbol reference to an
object that is not visible in all namespaces may cause problems. It
creates a cross-namespace reference that breaks down the isolation.

One possible solution is to expose the COPY relocation to the
sub-namespaces en-masse.

For example any COPY relocations processed in the base namespace can
be exposed in a "COPY relocation stub library" data structure that
is placed in the child namespace and available for linking with
when the child namespace attempts to resolve such symbols. This will
create the proper forwarding of all COPY relocations to the right
in-use location.

This would allow things like stdin, stdout, stderr and __environ to
be properly handled in the namespace when they are COPY relocated
into the binary.

Thoughts on the concepts and ideas?

-- 
Cheers,
Carlos.

[1] https://www.sourceware.org/ml/libc-alpha/2018-08/msg00418.html
[2] libcapsule:
    https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/
    https://www.reddit.com/r/programming/comments/9mzvb0/libcapsule_segregated_dynamic_linking/