[Bug dynamic-link/30186] RTLD_DEEPBIND interacts badly with LD_PRELOAD

["parky at outlook dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30186

--- Comment #2 from Matthew Parkinson <parky at outlook dot com> ---
So based on a suggestion from a colleague Paul Lietar, we have an alternative
suggestion that is less invasive. 

Previously, the malloc hooks provided a layer of indirection which has now been
removed.  We wonder if you could reintroduce the layer of indirection but only
accessible to the loader.

If you make 

   extern void* malloc(size_t s)
   {
     return __libc_malloc(s);
   }

Now, if you prevent inlining of __libc_malloc, then you can expose
__libc_malloc as something that can be overridden by LD_PRELOAD.  As an
RTLD_DEEPBINDed library would call malloc, this would immediately jump to what
ever symbol exists for __libc_malloc, when libc was loaded, and this would
account for LD_PRELOAD.

I have an example that suggests this could work:

  https://github.com/mjp41/deepbindexample/tree/main/solution

Many allocators already provide symbols for __libc_malloc, e.g.:

https://github.com/microsoft/mimalloc/blob/dd7348066fe40e8bf372fa4e9538910a5e24a75f/src/alloc-override.c#L273-L285

https://github.com/jemalloc/jemalloc/blob/09e4b38fb1f9a9b505e35ac13b8f99282990bc2c/src/jemalloc.c#L3143-L3175

So these would just start working with RTLD_DEEPBIND.

The obvious question is how much performance would be lost in adding the
indirection.  It would not affect existing allocator overrides as they could
override both, but for programs using the libc allocator, there would be a
cost.

I am sure there are many complexities that I am missing, but I thought this is
worth mentioning.

-- 
You are receiving this mail because:
You are on the CC list for the bug.