From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id EE7063857C78 for ; Wed, 28 Jul 2021 06:17:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE7063857C78 Received: by mail-lf1-x135.google.com with SMTP id f18so1826299lfu.10 for ; Tue, 27 Jul 2021 23:17:17 -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:to:cc; bh=xz2SUwFNWYmVrNgj3RzxcPHWaazdb/eFmzUkQlbo4ao=; b=o5ygL1/6o92ACYlDsph/GnHFWCMR6PyHYcD9Hh3G2QuKUWvrZMHfBtgReDhrVfR+/x EI9aZxNT9264GeVVRCMudMN59IAihq8/+99OMb8OU6xbFdtOF5zJBVV8wPLVz8NmnoA0 WvAV3j2UeapIlDDzA63AQo4mrXHiNO2ZBo8msno4zKs45Nu1TQ+C2z5/EjkW7RQ2uSMX Noy9lQRXIYVWm/MntsQd7EwI1ITQ+Sg9auFe70HlwPqMD0e7opWLh2AHzPR92+31v55L Jp5J+glC3tmI5RIbAufObUFcgjye5ouQPD0bK6tVYif/YFM5BxuudCF+LT/TQ7a9GCF1 5rZw== X-Gm-Message-State: AOAM531ZAkaSR9FrdrpR5NtYdPFxquyV5d6TphwLWx0NKSgWn2+sl2wj zWWgnuR0xpvOE7IL3Ri1+qwJgMWrma0spIz+vxA= X-Google-Smtp-Source: ABdhPJxKQRO/j1M6lPwmUNGETiSItKQWVQvFIS2Zkw8y99m9YxWWuyUmQ5ZTIb3i6K5QfBmTXi3HgcQjub4VUN8hc04= X-Received: by 2002:a05:6512:33a5:: with SMTP id i5mr18704331lfg.21.1627453036685; Tue, 27 Jul 2021 23:17:16 -0700 (PDT) MIME-Version: 1.0 References: <81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org> In-Reply-To: From: Fengkai Sun Date: Wed, 28 Jul 2021 14:17:05 +0800 Message-ID: Subject: Re: Enable preloading in dlopen-ed shared libraries? To: Adhemerval Zanella 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_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, 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 06:17:20 -0000 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. 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). 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. -- Best, Fengkai