[PATCH v2 0/2] malloc: introduce ifuncs for malloc functions

[H.J. Lu]

On Thu, May 7, 2026 at 4:32 PM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
>
> On Thu, May 07, 2026 at 09:22:33AM +0200, Florian Weimer wrote:
> > * Wilco Dijkstra:
> >
> > > Hi Florian,
> > >
> > >> I looked at this recently and it's rather desirable to tag chunks added
> > >> to tcache so that they can be returned directly from a future malloc
> > >> call.� This means that memory tagging cannot be implemented as a pure
> > >> wrapper.
> > >
> > > That's QoI. The existing implementation always untags and retags in tcache -
> > > this allows detection of use after free (or double free) and using the chunk
> > > for internal data.
> >
> > User after free detection is slightly *more* reliable if you directly
> > switch to the next random tag (different from the current tag) during
> > free.  If free switches to the metadata tag and malloc tags memory with
> > a random tag, 1 in 16 malloc-free-malloc cycles does not change the tag.
> >
> > > You could retag only on free and not on malloc, but having chunk structs
> > > that overlap user data makes all this tricky unfortunately. The tcache code
> > > could in principle not use internal data or we could retag only the size of
> > > the chunk struct.
> >
> > Even with an implicit tag verification architecture, I don't see how
> > user-tagged chunks in tcache cause problems.  The pointer comparisons in
> > the main allocator are problematic if the tags don't match as expected,
> > but I don't think that exists in tcache.
> >
>
> I agree that tagging chunks would be the most elegant solution.
> Unfortunately, in practice it causes problems: the existing
> implementation of memory tagging has become broken because changes to
> the internal malloc handling of chunks has not respected tagging that
> had been embedded into the malloc code. Not having tests (and hardware)
> didn't help.
>
> Also, tagging the entire chunk means that the chunk metadata can be
> accessed via the user pointer, which is not ideal.
>
> Implementing memory tagging as a layer is the only choice for the Glibc
> malloc.
>
> However, ifuncs are useful for other things: they enable targets
> implement their own functions (wrappers or entire implementations). We
> would also be able to use this approach for things like malloc check
> since the check can be implemented as a wrapper for core functions.
>
> Having ifuncs will allow to move all AArch64-specific memory tagging
> code to sysdeps, and whatever is done there will not affect other
> targets. Right now fixing, maintaining and making any changes to memory
> tagging requires modifying generic code. This means a lot of testing and
> much higher probability to cause a regression, functional or
> performance. We have to have these ifuncs.
>

Ifuncs mean indirection.  Will x86 also get indirection for malloc calls with
this patch?

-- 
H.J.