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

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Matthew Parkinson from comment #2)
> 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

This essentially adds another PLT indirection on *all* memory allocations, even
for default binaries that do no dlopen or do not use RTLD_DEEPBIND.  I don't
think this is a good tradeoff.

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

__libc_malloc is a strong alias to malloc, so there is no need to override for
shared libraries. Jemalloc states it is required to enable static linking,
which I am not sure it is true any longer (as long the malloc implementation
implements all requires functions).

> 
> 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 don't think the performance overhead is acceptable, and I am almost sure
other maintainers will frown upon it as well.

I really think a tunable or an extra option on LD_PRELOAD would be better to
instruct that RTLD_DEEPBIND should always consider LD_PRELOADS libraries on
namespace resolution.  It has the advantage of being backportable (where a new
symbol indirection would require another set of symbols).

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