Re: aarch64: Memory tagging modes proposal

On Tue, Aug 18, 2026 at 02:52:50PM +0100, Yury Khrustalev wrote:
> On Tue, Aug 18, 2026 at 10:22:34AM -0300, Adhemerval Zanella Netto wrote:
> > 
> > On 18/08/26 07:03, Yury Khrustalev wrote:
> > > On Mon, Aug 17, 2026 at 04:14:17PM -0300, Adhemerval Zanella Netto wrote:
> > >>
> > >> On 11/08/26 10:40, Yury Khrustalev wrote:
> > >>> Request for feedback.
> > >>>
> > >>> This is a proposal for how MTE binary marking from [1] should co-exist with
> > >>> the MTE Glibc tunable (not yet implemented). In my opinion, both are necessary
> > >>> to cover all practical use cases and provide both flexibility of future
> > >>> experiments and ease of configuration for developers and end users. This
> > >>> explain how it all should work.
> > >>>
> > >>

To streamline the discussion, could we come back to the basics first. I'd like to only
consider the initial process setup at this point (e.g. what happens during dlopen is
out of scope here).

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.

Let's agree about these basic principles and take it from here. Does it
sound reasonable?

Thanks,
Yury