From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Fengkai Sun <qcloud1014@gmail.com>, Libc-help <libc-help@sourceware.org>
Subject: Re: Enable preloading in dlopen-ed shared libraries?
Date: Fri, 23 Jul 2021 18:00:38 -0300 [thread overview]
Message-ID: <81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org> (raw)
In-Reply-To: <CAF6YOcO=rm2THiDh-VAa-V23jnWrZU2DcrSk5g4C=k3H9fL8Xg@mail.gmail.com>
On 14/07/2021 05:44, Fengkai Sun via Libc-help wrote:
> Hi list,
>
> As I dive a little deeper into the source code, I found that
> `_dl_map_object_deps' is called in both rtld.c and dl-open.c.
>
> The semantics of two invocations are both clear: rtld.c makes a call like
> this:
> _dl_map_object_deps (main_map, preloads, npreloads, mode == trace, 0);
> because ld.so needs to preload the libraries specified by LD_PRELOAD into
> the global scope for interposing the symbols.
>
> dl-open.c makes a call like this:
> _dl_map_object_deps (new, NULL, 0, 0,
> mode & (__RTLD_DLOPEN | RTLD_DEEPBIND | __RTLD_AUDIT));
> because no dlopen-ed library needs to preload anything.
>
> However, I think it might be useful to allow users to preload some
> libraries in the local scope after the map of the dlopen-ed library, just
> like how ld.so treats preloaded libs in global scope.
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?
>
> 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?
>
> 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.
It means that symbol interposition for heap functions you described does
not fit with the interfaces: LD_PRELOAD are already taking precedence
over the global scope and using a difference namespace meaning a different
scope.
next prev parent reply other threads:[~2021-07-23 21:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-14 8:44 Fengkai Sun
2021-07-23 21:00 ` Adhemerval Zanella [this message]
2021-07-24 2:51 ` Fengkai Sun
2021-07-26 19:51 ` Adhemerval Zanella
2021-07-27 13:23 ` Vivek Das Mohapatra
2021-07-28 6:17 ` Fengkai Sun
2021-07-28 18:09 ` Adhemerval Zanella
2021-07-28 19:02 ` Geoff T
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81d3637d-8ea4-4048-98de-584e813ddeaf@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-help@sourceware.org \
--cc=qcloud1014@gmail.com \
/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).