From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
To: libc-alpha@sourceware.org
Subject: Re: [RFC][PATCH v12 5/8] Implement dlmopen RTLD_SHARED flag (bug 22745)
Date: Mon, 9 Aug 2021 17:30:52 -0300 [thread overview]
Message-ID: <e05da1d1-6db4-c1db-8f95-490fde6195c5@linaro.org> (raw)
In-Reply-To: <20210708163255.812-6-vivek@collabora.com>
On 08/07/2021 13:32, Vivek Das Mohapatra via Libc-alpha wrote:
> This flag will instruct dlmopen to create a shared object present
> in the main namespace and accessible from the selected namespace
> when supplied in the MODE argument.
>
> include/link.h: Update the link_map struct to allow proxies
>
> We already have an l_real pointer, used for a similar purpose by
> the linker for copies of ld.so in secondary namespaces. Update its
> documentation and add a bitfield to indicate when link_map entry
> is a proxy.
>
> elf/dl-object.c: Implement a helper function to proxy link_map entries
>
> Provides the minimal functionality needed to take an existing
> link_map entry and create a proxy for it in the specified namespace.
>
> elf/dl-load.c, elf/dl-open.c: Implement RTLD_SHARED dlmopen proxying
>
> This uses the new infrastructure to implement RTLD_SHARED object
> proxying via dlmopen: Instead of opening the specified object in
> the requested namespace we open it in the main namespace (if it
> is not already present there) and proxy it to the destination.
>
> The following rules apply:
>
> If a proxy of the object is already present in the requested namespace,
> we simply return it (with an incremented direct-open count).
>
> If the object is already present in the requested namespace, a dl
> error is signalled, since we cannot satisfy the user's request.
>
> Proxies are never created in the main namespace: RTLD_SHARED has no
> effect when the requested namespace is LM_ID_BASE.
>
> elf/dl-fini.c: Handle proxy link_maps in the shutdown path (bug 22745)
>
> When cleaning up before exit we should not call destructors or
> otherwise free [most of] the contents of proxied link_map entries
> since they share [most of] their contents with the LM_ID_BASE
> objects to which they point.
>
> elf/dl-init.c: Skip proxy link_map entries in dl init path
>
> Proxies should not trigger calls to DT_INIT constructors since they're
> just shims that point to the real, already loaded and initialised, objects.
>
> elf/dl-open.c: Skip libc init if namespace has no libc map
>
> Secondary namespaces which share their libc mapping with the main
> namespace cannot (and should not) have _dl_call_libc_early_init
> called for them by dl_open_worker.
>
> elf/dl-open.c: When creating a proxy check NS 0 libc map
>
> The libc_already_loaded check normally considers the libc_map entry
> in GL(dl_ns)[args->nsid].libc_map.
>
> This is not correct for proxies, which use the libc_map from
> the default namespace (as proxies are dummy entries that point
> to the base namespace via their l_real members).
>
> elf/dl-load.c, dl-open.c: Compare DSOs by file ID & check DF_GNU_1_UNIQUE
>
> If _dl_map_object_from_fd finds that a DSO it was asked to
> load into a non-base namespace is already loaded (into the
> main namespace) and is flagged DF_GNU_1_UNIQUE then it should
> return that DSO's link map entry.
>
> In such cases _dl_open_worker must notice that this has
> happened and continue down the link map proxy generation
> path instead of normal link map entry preparation.
>
> elf/dl-load.c: error if RTLD_SHARED = DF_GNU_1_UNIQUE semantics violated
>
> elf/dl-open.c: Use search helper to find preloaded DT_GNU_UNIQUE DSOs
>
> If a DSO already exists (with the same name) in the base namespace
> and it is flagged DT_GNU_UNIQUE then we should behave as if a proxy
> had been requested.
>
> elf/dl-load.c: When loading DSOs in other namespaces check DT_GNU_UNIQUE
>
> If a DSO has not already been loaded and the target is not the main
> namespace then we must check to see if it's been DT_GNU_UNIQUE tagged
> and load it into the main namespace instead.
>
> dl_open_worker has alread been modified to notice the discrepancy
> between the request and the result in such cases, and will set up
> a proxy in the target namespace.
>
> elf/dl-load.c: Suppress audit calls when a (new) namespace is empty
>
> When preparing an RTLD_SHARED proxy in a new namespace
> it is possible for the target namespace to be empty:
>
> This can happen for RTLD_SHARED + LM_ID_NEWLM.
>
> The audit infrastructure should not be invoked at this
> point (as there's nothing there to audit yet).
>
> bits/dlfcn.h, elf/dl-load.c, elf/dl-open.c, elf/rtld.c,
> sysdeps/mips/bits/dlfcn.h:
> Suppress inter-namespace DSO sharing for audit libraries
>
> Audit libraries should not participate in DSO sharing: In
> particular libraries tagged with DF_GNU_1_UNIQUE should not
> be shared between the audit namespace and any others - they
> should get their own copy.
>
> This is signalled to the loader code by passing the RTLD_ISOLATE
> flag from the relevant entry point in the dl modes argument.
>
> elf/dl-sym.c: dlsym, dlvsym must be able to resolve symbols via proxies
This new features should also have a NEWS entry.
next prev parent reply other threads:[~2021-08-09 20:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 16:32 [RFC][PATCH v12 0/8] Implementation of RTLD_SHARED for dlmopen Vivek Das Mohapatra via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 1/8] Define a new dynamic section tag - DT_GNU_FLAGS_1 (bug 22745) Vivek Das Mohapatra via Libc-alpha
2021-08-09 12:27 ` Adhemerval Zanella via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 2/8] Abstract loaded-DSO search code into a helper function Vivek Das Mohapatra via Libc-alpha
2021-08-09 13:04 ` Adhemerval Zanella via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 3/8] Use the new DSO finder " Vivek Das Mohapatra via Libc-alpha
2021-08-09 12:59 ` Adhemerval Zanella via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 4/8] Add DT_GNU_FLAGS_1/DF_GNU_1_UNIQUE to glibc DSOs (bug 22745) Vivek Das Mohapatra via Libc-alpha
2021-08-09 16:48 ` Adhemerval Zanella via Libc-alpha
2021-08-10 13:21 ` Adhemerval Zanella via Libc-alpha
2021-08-10 13:32 ` H.J. Lu via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 5/8] Implement dlmopen RTLD_SHARED flag " Vivek Das Mohapatra via Libc-alpha
2021-08-09 19:07 ` Adhemerval Zanella via Libc-alpha
2021-08-09 20:24 ` Adhemerval Zanella via Libc-alpha
2021-08-09 20:30 ` Adhemerval Zanella via Libc-alpha [this message]
2021-07-08 16:32 ` [RFC][PATCH v12 6/8] Add dlmopen / RTLD_SHARED tests Vivek Das Mohapatra via Libc-alpha
2021-08-09 20:09 ` Adhemerval Zanella via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 7/8] Restore separate libc loading for the TLS/namespace storage test Vivek Das Mohapatra via Libc-alpha
2021-08-09 19:08 ` Adhemerval Zanella via Libc-alpha
2021-07-08 16:32 ` [RFC][PATCH v12 8/8] Drop DT_GNU_FLAGS_1/DF_GNU_1_UNIQUE from the libpthread DSO Vivek Das Mohapatra via Libc-alpha
2021-08-09 20:10 ` Adhemerval Zanella via Libc-alpha
2021-08-09 21:24 ` Florian Weimer via Libc-alpha
2021-07-13 13:08 ` [External] : [RFC][PATCH v12 0/8] Implementation of RTLD_SHARED for dlmopen Alfonso Alfonso Peterssen via Libc-alpha
2021-08-09 20:34 ` Adhemerval Zanella via Libc-alpha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e05da1d1-6db4-c1db-8f95-490fde6195c5@linaro.org \
--to=libc-alpha@sourceware.org \
--cc=adhemerval.zanella@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).