From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 98B8C388C016 for ; Wed, 28 Jul 2021 19:02:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 98B8C388C016 Received: by mail-ed1-x531.google.com with SMTP id ec13so4141894edb.0 for ; Wed, 28 Jul 2021 12:02:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=UFSRjrhXSqBjvJXAO7QnWA8sYT+R+REZyEa0v158t9k=; b=m0af3SCAfg7kvqyuFGeUL6Ktnn4kpo89Xkef4J+vB1GHs5vCz04Ydq1g47lW7/IM8V 2FOh+DHXHehOB4qd39rjrwTZZIp2VQTkxGL8OrRCaIhSAGbqG9lOREyfiU+veJilqoxq y2jMweKU3yVZO49EKkoeFl+iek7eirOAS7W4ja1wNhhmkuL34h0/DMwCYSDj/3M4RQhL OwX80uy4QoJy5Wy6GrXrcfM5TDDMKcuvqYHvMx7uDNgQy1NPijCPUWkDBKQxWEjfbPuy mbO82m6zkFm2AeGFfeFJ/qPw+q6kALF0m04VBb237XFKhXNKrrBv4DWkm2aHF/Zi5KDw okPA== X-Gm-Message-State: AOAM532o5nm2xiM48J+bvWg9FiTS7IfOgD9laWhk4yh4ucdBktKUjEv0 wFYVZqi/dtJKYjmsamScwKo8u7DmxL0xGsJNrjJKXGuXM14= X-Google-Smtp-Source: ABdhPJxV8HoiPWYUkVIHi3/8vm0wePutvnzodBMyO6wu2PQxsdwLoIJtIGiEztk0z5vIoklQDMQpW5Kxz7nY16DKzFc= X-Received: by 2002:a05:6402:2789:: with SMTP id b9mr1476145ede.201.1627498945478; Wed, 28 Jul 2021 12:02:25 -0700 (PDT) MIME-Version: 1.0 References: <81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org> In-Reply-To: From: Geoff T Date: Wed, 28 Jul 2021 13:02:14 -0600 Message-ID: Subject: Re: Enable preloading in dlopen-ed shared libraries? Cc: libc-help@sourceware.org X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, MISSING_HEADERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 19:02:28 -0000 unsubscribe On Wed, Jul 28, 2021 at 12:09 PM Adhemerval Zanella via Libc-help < libc-help@sourceware.org> wrote: > > > On 28/07/2021 03:17, Fengkai Sun wrote: > > Hi Adhemerval, > > > > This seems very specific to add such complexity and extra internal state > >> on loader and I want to understand better the issue you are trying to > solve > >> and why you can't use the current tools instead. > >> > >> Thanks for your reply! I now realize that changing the interface of the > > dynamic linker needs reason and user cases that are solid and general > > enough. But originally I planned to ask if this is a good idea and if > there > > is an existing interface to achieve this. Thank you for the information > > provided! > > > > I will explain the original problem I want to solve here: > > > > We have an acadamic project which proposes a framework, and it should > load > > and isolate some external libraries completely, making them > self-contained > > and does not need to refer to anything outside their own namespace. > > Ideally, dlmopen would suffice, but I found that dlmopen can only support > > up to 16 namespaces, but we might use way more libraries than that. > > Do you need each library to be completely isolated from each other? Can't > you > load all of them in a single namespace or at least work around specific > sets > up to the 16 namespace limits? > > > > > So I came up with another solution to simulate multi-namespace inside > one: > > use dlopen and load the libraries all into the default namespace. To > > achieve complete isolation, I recursively renamed the dependencies of the > > external libraries to bypass the limitation of allowing only one instance > > inside a namespace. This is done by ELF patching tools, and I used > patchelf. > > For example, let's say there is a dependency graph like this: > > libexternal.so -> lib1.so; libexternal.so -> libc.so > > lib1.so -> libc.so > > libc.so -> ld-linux.so > > > > After the renaming, the filename and dependency names of each library is > > changed, so that ld.so will load another instance even if some libraries > > already exist in the default namespace. > > The dependency graph after renaming is like this: > > libexternal.so -> lib1-1.so; libexternal.so -> libc-1.so > > lib1-1.so -> libc-1.so > > libc-1.so -> ld-linux-1.so > > > > This is not a good solution because my understanding of glibc is quite > > shallow. dlopen seems to have problems in initializing libc and > libpthread > > when the filename of them are changed. So I tried not to rename libc or > > libpthread and made them shared(just like the RTLD_UNIQUE flag proposed > by > > Vivek). > > You seems to want unlimited namespace, which is different than what Vivek > is trying to fix with RTLD_SHARED / RTLD_UNIQUE. This should be doable by > adding an extra list on _rtld_global and handle all places that access the > _dl_ns link_namespaces (dlopen, dlclose, etc.). This would require some > work > on how we will handle static TLS (since this take in consideration the > maximum > number of namespaces). > > And you are correct, glibc internally check if DT_SONAME is the one > expected > by the hard-coded LIBC_SO. Trying to mess with it might broke in some > places > and that's exactly that dlmopen intends to provide. > > > > > And we also want to interpose the symbols inside the external libraries. > So > > I asked if there is a way to provide a different definition for symbols > in > > local scope, just like what LD_PRELOAD does to global scope. > > Currently I use patchelf to prepend a dependency, let's call it > > libpreload.so, in the dynamic section of libexternal.so, so that ld.so > will > > search the symbol for libexternal.so and its dependencies first in > > libpreload.so. Things are going well so far, and I will be very grateful > if > > you and other people on the list have a look at this solution. > > It seems that our use case is really rare, and a full-functioned > rtld-audit > > interface can solve the problem for it. > > The dlmopen should work to provide the symbol resolution for a specific > set of > libraries: you first load on the namespace and then load the set of > libraries. > > But without dlmopen I don't have a easy solution for you. If you are not > bounded > to the system glibc, you might change the DL_NNS internally to expected > number > of namespace. It has some implication, specially in the static TLS > requirement, > but I think it should work. > > I am not really against the local scope preload environment variable, but > this > will be another *very* specific feature that we will need to support > indefinitely > for an specific usercase that might not even used extensively (as you put > this is > a research project). This will also have some semantic issues we will need > to sort > out also, like how to represent an specific namespace (since glibc can > return any > value and Lmid_t does not need to map to an specific number). > >