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

[Yury Khrustalev]

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.

Thanks,
Yury