Re: Can LD_PRELOAD set different symbol definitions for shared objects and executable?

[Fengkai Sun <qcloud1014@gmail.com>]

Hi Florian,

Thanks for your help as always.

I've done some research on LD_AUDIT interfaces, and found it very useful to
me. However, I had some problems when implementing a separate malloc for
executable and shared objects:

I use la_symbind64 to monitor symbol binding. The pseudocode is as follows:
IF symname == "malloc" AND refcook == "shared objects"
    RETURN custom_malloc
ELSE
    RETURN malloc

Then I discovered I have no way to get the address of custom malloc in the
audit library...

I tried to dlopen the audit library, hoping it would return the handle for
the audit library, so that I could define a pointer in audit library
pointing to custom malloc.
However it turns out dlopen is mapping a new copy like this:
***dlopen-ed audit library***
7f798d9e6000-7f798d9e7000 r--p 00000000 08:02 130290069
/home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9e7000-7f798d9e8000 r-xp 00001000 08:02 130290069
/home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9e8000-7f798d9e9000 r--p 00002000 08:02 130290069
/home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9e9000-7f798d9ea000 r--p 00002000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9ea000-7f798d9eb000 rw-p 00003000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9eb000-7f798d9ec000 r--p 00000000 08:02 130290060
 /home/hypermoon/Qcloud/tst-setenv/mymalloc.so
7f798d9ec000-7f798d9ed000 r-xp 00001000 08:02 130290060
 /home/hypermoon/Qcloud/tst-setenv/mymalloc.so
7f798d9ed000-7f798d9ee000 r--p 00002000 08:02 130290060
 /home/hypermoon/Qcloud/tst-setenv/mymalloc.so
7f798d9ee000-7f798d9ef000 r--p 00002000 08:02 130290060
 /home/hypermoon/Qcloud/tst-setenv/mymalloc.so
7f798d9ef000-7f798d9f0000 rw-p 00003000 08:02 130290060
 /home/hypermoon/Qcloud/tst-setenv/mymalloc.so
***original audit library***
7f798d9f0000-7f798d9f1000 r--p 00000000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9f1000-7f798d9f2000 r-xp 00001000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9f2000-7f798d9f3000 r--p 00002000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9f3000-7f798d9f4000 r--p 00002000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so
7f798d9f4000-7f798d9f5000 rw-p 00003000 08:02 130290069
 /home/hypermoon/Qcloud/tst-setenv/libaudit.so

So I can't find a way to get the link map for the original audit library.

Also, moving the implementation of malloc directly into audit library will
result in a segfault that gdb isn't even able to run.

Can you give me some advice on how to work with it? Thank you very much.


Best,
Fengkai

On Tue, May 25, 2021 at 4:41 PM Florian Weimer <fweimer@redhat.com> wrote:

> * Fengkai Sun via Libc-help:
>
> > For example, if I set LD_PRELOAD="./mymalloc.so", then all references to
> > malloc will be interposed. There is no way to specify a custom allocator
> > only for shared objects(maybe I can make a difference in the source code
> of
> > custom malloc, but that's off topic).
>
> Yes, LD_* variables are captured at startup, and changing their values
> later using setenv etc. does not have an impact on the current process.
>
> > I wonder if there is any way to do this, or if I missed out some
> > fundamental ideas.
>
> It is possible to do this using the LD_AUDIT framework.
>
> Thanks,
> Florian
>
>