From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by sourceware.org (Postfix) with ESMTPS id D2AA33858C3B for ; Sat, 24 Jul 2021 02:51:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2AA33858C3B Received: by mail-lf1-x12e.google.com with SMTP id y34so5138093lfa.8 for ; Fri, 23 Jul 2021 19:51:15 -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=VihI1OZrfVLDi1MhKJyyKV442P+lBdJYmqz9rMhQbTk=; b=BNwfa8DSzcxNbW6EY7C8e1WUTDB8enwjFbsxV3RZXgpVe4WUUNM19dN/43lvhot/QT Pze/JpVZkvE/sTWhPgM6fz0k5RhA0l+gATg7oC1HK5nblwlX06yTk+NBM5VTOppuQn2C t/YUEUFn/XpMePGYFJYjiyDUmpmcRt09JRrHUzyp0nLIQBov98rqYcaBVNE8Fo4gq9oW VRUBUz4Ci2Aj0mvauabIQkCZdskXAnFaw4l/nNkXLcXRwJt0Z8wehTO5MupMhGXw7Ubp K5gfTBoXfUNNTAYdWb49NjSLMi4WCzsa5xnUlgVpFdE1NWUBHAgrlTVtNxdtKELH1+ld WT7A== X-Gm-Message-State: AOAM530bLkoR9Nd21drNSp3LqfdJMOJZhE5oluozMBp9fA4A14DdKQhs RiLN1iIeAPfohnoE6a8J1+vMiVqA/WDdzuXuxM4= X-Google-Smtp-Source: ABdhPJzamx9yk14eGtKRIi0T8bp2Bbjm7GyRZqmhEP1/kDfyH7vaBNIlhsvspUiH6pIPrJ7KSNaZtm39STE6hitK9gQ= X-Received: by 2002:a05:6512:33a5:: with SMTP id i5mr4818676lfg.21.1627095074396; Fri, 23 Jul 2021 19:51:14 -0700 (PDT) MIME-Version: 1.0 References: <81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org> In-Reply-To: <81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org> From: Fengkai Sun Date: Sat, 24 Jul 2021 10:51:03 +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.3 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: Sat, 24 Jul 2021 02:51:17 -0000 Hi Adhemerval, Thanks so much for your reply! I will explain my idea in detail and sorry for the unclearness. Do you mean by preloading the shared library list using dlmopen in a new > namespace? Or do you mean to use RTLD_DEEPBIND with the preload libraries? > I mean making users able to specify a list of preload libraries in a shared library's local scope, so that when the library is loaded with RTLD_DEEPBIND on, the preload libraries will take precedence over any other library except the dlopen-ed one. > By doing so, the user can easily provide a different definition of a > symbol > > from the one of the main executable, by enabling RTLD_DEEPBIND. > > This is useful under some circumstances. For example, a dlopen-ed library > > may want to use a separate heap from the main heap, and the user can > > provide another malloc implementation for that library. > > But how is this different than the malloc() interposition already supported > with LD_PRELOAD? > I found that LD_PRELOAD cannot provide a different definition for a dlopen-ed library from the main executable. Let's say we are preloading mymalloc.so in an executable: scope0(global scope): ./main_exe mymalloc.so libc.so libdl.so So the reference in the main executable is binded with the definition in mymalloc.so. A dlopen-ed shared library will have such kind of scope, let's call it lib1.so: scope0(global scope): ./main_exe mymalloc.so libc.so libdl.so scope1(local scope): lib1.so libc.so If lib1.so is loaded without RTLD_DEEPBIND, its reference to malloc will be binded to mymalloc.so too. That means shared libraries and the main executable are using the same heap, sometimes the user may want to prevent it. My goal is to preload libraries inside local scope, and it will look like: scope1(local scope): lib1.so othermalloc.so libc.so In this way, the main executable will never see the definition inside othermalloc.so, and lib1 can bind to it when RTLD_DEEPBIND is on. > The auditing interface can do the similar thing, but after doing some > > experiments, I found that `la_symbind64' cannot catch the bindings of > > global variables, and it cannot hook all of the function bindings. > > The rtld-audit currently only works for symbols which requires a PLT call, > the global variables either done with GOT access directly or through copy > relocations. I am working on extending la_symbind() to work with bind-now > binaries, so it would be called at loading time in symbol resolution > instead > on the lazy binding resolution. > > > > > Would it be a good idea to add an interface to enable preloading in the > > local scope of dlopen-ed shared libraries? > > I am trying to understand better what you are trying to do here, because > you are mixing two different usercases here. The RTLD_DEEPBIND is usually > used for shared libraries to use its direct dependencies over the global > list, the rtld-audit interfaces are loaded in a different namespace. > I mentioned the rtld-audit interface here because it could provide different definitions for the same symbol. In la_symbind(), the user can return a different symbol address other than sym->st_value to achieve this: void *mymalloc(...) {...} void *la_symbind(...){ if (refcook == lib1_cook && strcmp(symname, "malloc") == 0) return mymalloc; else return sym->st_value; } However, la_symbind() currently happens in lazy binding resolution(thank you for clarifying it!), so it cannot work on every symbol for now. Again, I'm sorry for mixing RTLD_DEEPBIND, dlmopen and rtld-audit all together in the first email. I hope I've made things clear now. -- Best, Fengkai