[PATCH 2/2] malloc: change tunable glibc.mem.tagging to glibc.mem.aarch64_mte

[Yury Khrustalev]

On Wed, Mar 25, 2026 at 02:28:24PM -0300, Adhemerval Zanella Netto wrote:
> 
> On 20/03/26 08:36, Yury Khrustalev wrote:
> > The 'glibc.mem.tagging' tunable was added as a generic tunable although
> > at the time memory tagging was only supported by aarch64.
> > 
> > The values for such a tunable are likely to be target-dependent.
> > 
> > This commit removes 'glibc.mem.tagging' and instead adds a new target
> > specific tunable 'glibc.mem.aarch64_mte' that accepts string values:
> > 
> >  - 'none': memory tagging is disabled (the default).
> >  - 'auto': enable CPU preferred tag checking mode.
> >  - 'sync': enable synchronous tag check fault mode.
> >  - 'async': enable asynchronous tag check fault mode.
> > 
> > This tunable affects the flags used for the PR_TAGGED_ADDR_ENABLE
> > prctl syscall and only has effect when the system supports HWCAP2_MTE.
> > 
> > This commit also changes when this prctl syscall happens. There are
> > three stages:
> > 
> >  1) Check if the system supports HWCAP2_MTE and get the value of
> >     the 'glibc.mem.aarch64_mte' tunable if it does.
> >  2) Check ELF marking and amend 'aarch64_mte' value if necessary
> >     (note: this commit doesn't add any actual checks here, just
> >     the way to implement them if required).
> >  3) Make the prctl syscall based on the 'aarch64_mte' value.
> > 
> > If some MTE mode was requested but the prctl call failed, it is an error.
> > 
> > The Glibc manual has been updated accordingly.
> 
> This patch should be marked as RFC since it ties the MTE support to
> your proposed GNU attributes [1]

I'm not sure what you mean, there is no mention of those proposed
attributes in this patch at all.

> and it still has missing semantic
> on how to enable GLRO(dl_aarch64_cpu_features).mte.

This internal flag was used as a copy of the value loaded from the
glibc.mem.tagging tunable. This wasn't useful and in this patch series
I change this field to merely indicate if HWCAP2_MTE is supported.

I'm not sure what you mean by

  semantic on how to enable GLRO(dl_aarch64_cpu_features).mte

> 
> [1] https://github.com/ARM-software/abi-aa/issues/382
> 
> ...
> 
> > diff --git a/malloc/arena.c b/malloc/arena.c
> > index 2f894d21e9..8c09aefce1 100644
> > --- a/malloc/arena.c
> > +++ b/malloc/arena.c
> > @@ -253,14 +253,13 @@ __ptmalloc_init (void)
> >  #endif
> >  
> >  #ifdef USE_AARCH64_MTAG_HEAP
> > -  if ((TUNABLE_GET_FULL (glibc, mem, tagging, int32_t, NULL) & 1) != 0)
> > +  if (__libc_mtag_enabled ())
> >      {
> > -      /* If the tunable says that we should be using tagged memory
> > +      /* If we should be using tagged memory
> 
> I think it makes sense to move the memory tag support to arch-specific
> mode (GLRO(dl_aarch64_cpu_features).mte in this case).

We cannot use this arch-specific thing explicitly here, hence the
function '__libc_mtag_enabled'. There is also a reason why we don't
use 'GLRO(dl_aarch64_cpu_features).mte' inside that function.

> 
> ...
> 
> > +  /* HWCAP2_MTE is not supported: nothing to do.  */
> > +  if (!GLRO (dl_aarch64_cpu_features).mte)
> > +    return;
> > +  int t = GL (dl_aarch64_mte);
> > +  uint64_t flags = PR_TAGGED_ADDR_ENABLE | MTE_ALLOWED_TAGS;
> > +  switch (t)
> > +    {
> > +    case MTE_TUNABLE_NONE:
> > +      return;
> > +    case MTE_TUNABLE_AUTO:
> > +      flags |= PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC;
> > +      break;
> > +    case MTE_TUNABLE_SYNC:
> > +      flags |= PR_MTE_TCF_SYNC;
> > +      break;
> > +    case MTE_TUNABLE_ASYNC:
> > +      flags |= PR_MTE_TCF_ASYNC;
> > +      break;
> > +    default:
> > +      _dl_fatal_printf ("unknown MTE tunable value: %d\n", t);
> > +    }
> > +  int r = INLINE_SYSCALL_CALL (prctl, PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0);
> > +  if (r == -1)
> > +    _dl_fatal_printf ("failed to enable MTE: %d\n", -r);
> > +}
> > +
> 
> This moves MTE enable later in process creation, currently it is done
> init_cpu_features issued by the loader; which now __libc_mtag_init will
> be called during _start from the process.

If we want to take into account ELF marking (whatever form it comes in),
we cannot make prctl syscall in 'init_cpu_features' because markings are
scanned later. Also 'init_cpu_features' is not the best place for syscall
that may fail. And we cannot make more than 1 syscall with possibly
conflicting parameters.

> It has the side-effect of disabling MTE hardening for some loader malloc
> calls; after the self-relocation / __rtld_malloc_init_real call.  This
> will be same for a possible stack tagging support.

This is the price we pay for using ELF marking.

Thanks,
Yury