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

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

[Fengkai Sun]

Hi list,

I've done some research on elf/rtld.c, and found that the dynamic linker
only handles the preload list in dl_main, that is, there is no other way to
change it later.

Does that mean there is no way to give different symbol definitions to
shared objects and executable?

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).

I wonder if there is any way to do this, or if I missed out some
fundamental ideas.


Best,
Fengkai

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

[Florian Weimer]

* 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

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

[Fengkai Sun]

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
>
>

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

[Florian Weimer]

* Fengkai Sun:

> 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...

Hmm, malloc may be very special here because ld.so and libc.so in the
base namespace really must use the same malloc, or things will fall
apart.  In principle this code should work, and I expect with a lot of
care, it can be made to work for malloc as well.

Thanks,
Florian