Re: Overriding malloc

[Florian Weimer <fweimer at redhat dot com>]

On 07/01/2014 06:09 PM, Rich Felker wrote:
> On Tue, Jul 01, 2014 at 10:28:37AM +0200, Florian Weimer wrote:
> > We need to support overriding malloc through LD_PRELOAD and other
> > forms of symbol interposition.  Once you override malloc, you also
> > have to override free, realloc and calloc at least.
> >
> > If the application (or one of its libraries) uses posix_memalign
> > etc., these have to be overridden as well.  Same for the
> > malloc_usable_size.
>
> Don't forget aligned_alloc (C11). This is one that's likely to be
> overlooked in any malloc replacement since it's so new. And
> aligned_alloc can't just call posix_memalign or memalign as its
> implementation to work around the problem, because the latter are,
> with respect to C11, in the namespace reserved for the application.

Oh well, looks like you are right.  Conversely, a malloc replacement 
library cannot override them because they are outside the namespace, too.

> > The question is if overriding those should is required even if the
> > application does not call those fringe malloc-related functions,
> > i.e. if glibc should behave as if it never calls them if malloc has
> > been overridden.
> >
> > If yes, we should likely remove the remaining call to
> > malloc_usable_size from the code base.
>
> Even if glibc behaves as if it does not call these "extra" functions,
> it's very hard for an application (to guarantee that none of the
> third-party libraries it links to does so).
>
> If you really want to "officially" support overriding malloc rather
> than having it be a nasty hack that "probably works",

At least from a downstream perspective, I'm pretty sure we can't 
disclaim support for it because it's what users do—it's simply a fact of 
life, even though it can be rather inconvenient at times.

> I think there
> needs to be some dynamic-linking magic that checks that a malloc
> replacement overrides ALL malloc-system functions together, and to
> either issue an error or suppress all the definitions if any are
> missing.

I don't think anything besides an error will work because user-supplied 
allocation functions could be called by alternative names.

--
Florian Weimer / Red Hat Product Security