Re: aarch64: Memory tagging modes proposal

On Wed, Aug 19, 2026 at 07:46:30PM +0200, Florian Weimer wrote:
> * Yury Khrustalev:
> 
> > Are we on the same page about this:
> >
> > 1) There are two things to configure:
> >     - memtag scope: heap, stack, globals (I refer to these as 'components')
> >     - memtag mode: sync, async, asymm, auto
> >
> > 2) The 3 components for the scope (heap, stack, globals) can *in theory*
> >    be enabled and disabled independently of each other (so whatever
> >    configuration we provide should allow for this independent on / off
> >    switch for each of the 3 components).
> >
> > 3) If memtag protection is enabled for at least one of the 3 components,
> >    we need to do 2 things:
> >     - prctl(PR_SET_TAGGED_ADDR_CTRL, ...)
> >     - start using PROT_MTE for mmap / mprotect for the memory that is
> >       relevant for the enabled components
> >
> > 4) When we do that prctl syscall, we use the scope to determine which
> >    flags to use for this syscall.
> 
> I think we need a statement of requirements *why* this needs to be
> configurable at all, and then work out what that means for the
> implementation.

The *why* comes from the need to support the features that the architecture
and the ABI provide.

> 
> A few possible reasons:
> 
> * The tag bits confuse existing software.  (There are various subcases.)
>
> * Existing software assumes page-size access granularity and overreads.
> 
> * Tag checking needs to be disabled to meet performance goals.
> 
> There might be more compatibility aspects.
> 

These are all valid examples that are supposed to be covered by that the
memory tagging is opt-in. However, when user do opt-in to use memtag protection,
they still have a number of choices that we should accommodate.

My goal hear is to avoid blocking of any use cases even we don't see any
immediate value in them or don't understand why these use cases are important.

Thanks,
Yury