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

[Yury Khrustalev]

On Mon, Apr 20, 2026 at 12:06:03PM -0400, DJ Delorie wrote:
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
>
> ...
>
> > This is the fragile part of any abstractions around malloc
> > (ifunc-based or otherwise).
> 
> Yeah, that's why I put my thoughts in writing, in case they were faulty.
> 
> > Off-topic, but I think that all internal _core functions should operate on
> > something like
> 
> In practice, most operate on a CHUNK* (mchunkptr) but we don't have a
> special type for pointers to the user data part.

Yeah, and CHUNK* is not distinguishable from any other raw pointer from
the C language point of view. If it was like this:

typedef struct {
  struct malloc_chunk *chunk;
} mchunkptr;

then chunk pointer would be a different type and it would be not easy to
accidentally mess things up.

Part of the reason why current memtag implementation in malloc is broken
is because user and chunk pointers got mixed up.

> >> I wonder, though... we current do tagging operations inside malloc
> >> internals, like splitting chunks.  How will the ifunc interface handle
> >> these?
> >
> > That's left for the next patch series, stay tuned! Core parts of malloc
> > should not be aware of any tagging or whatnot. I'm working on it now.
> 
> I will find it interesting how you do that, because we intentionally
> change the tagging when we do that to avoid certain types of attack
> vectors.

I have a draft patch, but it depends on this patch series. I'll post it
as soon as we have this settled and merged.

The threat model that we are trying to address with memory tagging in
malloc will have to evolve over time as we need to look after
performance as well. At this stage we need to make it right functionally
first so we have functional reference point for making changes to harden
or optimise the implementation.

> >> It would be nice if there were some hint as to what these arguments are,
> >> or are used for.  Ifuncs are complicated enough without obfuscating this
> >> information.
> >
> > That's why I kept them as part of macro arguments. Perhaps, we should make
> > it even more explicit. I'll think about it. Maybe at least argument types
> > should be here too. As for the names, I think they have to be pretty generic.
> 
> Sorry, I meant the names should give a hint as to what the arguments
> *are*, or a comment that says "these will be passed the following
> data...".

Yes, I got this I think. I've posted v2 where I changed this bit. The
generic versions of resolvers will have to have no arguments, as this is
how ifunc resolvers are supposed to be. Target-specific ones may have
args as per respective ABIs (e.g. in aarch64 we have 2 uint64_t).

> Just saying "arg0" and "argv[]" tells the reader nothing about what
> those values *mean* or where they come from.

I agree. Since it's target dependent, I will add brief description and
the link to the document that explains the arguments in details.

Cheers,
Yury