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

[Yury Khrustalev]

On Thu, May 07, 2026 at 11:40:03AM +0200, Florian Weimer wrote:
> * Yury Khrustalev:
> 
> >> 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.
> 
> This doesn't matter to tcache because it's the outer allocator.  I'm
> pretty sure that this works, after verifying outer allocator behavior
> with software tag checking.  We must be careful not to pass tagged
> pointers (or use tagged memory) in the inner allocator.
> 
> > Also, tagging the entire chunk means that the chunk metadata can be
> > accessed via the user pointer, which is not ideal.
> 
> Oh, I'm still reserving tag zero as the metadata tag.  The previous user
> pointer cannot be used to access the tcache metadata because the tag has
> changed.
> 
> > Implementing memory tagging as a layer is the only choice for the Glibc
> > malloc.
> 
> I have come to a similar conclusion, except for tcache.  It's itself
> layered on top of the inner allocator, so we can make sure that we feed
> only untagged pointers to allocator below.

Code-wise, tcache is interleaved with core malloc code, much like the
existing memory tagging. To fix the latter, I'm working on extracting
all memory tagging from malloc.c and arena.c into a separate target-
specific place.

Until tcache is extracted in a similar way, I don't think it's worth
implementing any memory tagging for it.

Thanks,
Yury