Re: dlmopen and variables in the dynamic loader

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

On 8/19/19 7:27 AM, Florian Weimer wrote:
> * Zack Weinberg:
> 
>> 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...)
> 
> Requirements among applications vary drastically, I fear.  For example,
> some might want to load a single copy of SQLite, so that the locking
> works correctly even if a database file is opened multiple times by one
> process.  Others may want multiple versions of SQLite, so that each part
> of the application uses the version of SQLite it has been tested with.

I agree. I don't know if this choice can be made by the author of the
application, it needs to be made by the integrator, which seems like it
should be dlopen flags base.

At the moment we are discussing:

(1) No proxy. Only ld.so is the same across all the namespaces.
(2) glibc proxy. All of the implementation is hared across all namespaces.

My thought is that in (1), which we have today, it's unsafe for any
thread to cross a namespace boundary, only ld.so code should be runnable
as part of the thread creating the new namespace, and then return. This
means that loaded shared libraries can run pthread_create as early as
their initializers using the namespace's own libpthread.

In the case of (2) we can have threads cross namespace boundaries and
run arbitrary user code because libpthread is shared.

It still seems like we need to forward COPY relocations in the case of
(1) and (2) for glibc components, but it feels like anything above glibc
needs a flag to indicate on a per component basis if COPY relocations should
forward or not e.g. __RTLD_COPY_FORWARD, but this would be a *terrible*
design for users.

Users I think can make choices like

(a) Only the dynamic loader shared - "Base" implementation and up is isolated.
(b) Only the "Base" implementation is shared - Users libraries and up are isolated.

orthogonal to this:

(c) Flag for "Strong isolation" or "Weak isolation" e.g. RTLD_NM_STRONG, RTLD_NM_WEAK
    - Strong isolation involves no shared COPY relocs.
    - Weak isolation involves shared COPY relocs.
    - Put future changes into one of two buckets.

Just talking out loud at this point...

-- 
Cheers,
Carlos.