Re: aarch64: Memory tagging modes proposal

On Thu, Aug 27, 2026 at 06:08:27PM -0300, Adhemerval Zanella Netto wrote:
> 
> On 26/08/26 05:43, Yury Khrustalev wrote:
> > On Tue, Aug 25, 2026 at 10:07:31AM -0300, Adhemerval Zanella Netto wrote:
> >>
> >> ...
> >>
> >> The deeper problem is that the tunable answers two orthogonal questions
> >> with one value:
> >>
> >> * which fault mode?
> >> * is heap tagging enabled for unmarked binaries?
> > 
> > Technically, these are orthogonal, but
> > 
> >  | ---------------------------- |
> >  |  on  | sync | async | etc... |
> >  | ---------------------------- |
> >  |  off |  --  |  --   |  --    |
> >  | ---------------------------- |
> > 
> > there is only one dimension of meaningful combinations.
> > 
> >> Which means neither can be expressed independently.
> > 
> > Can you give an example that cannot be expressed?
> > 
> >> An admin who wants heap
> >> tagging on unmarked binaries but has no opinion on mode to select
> > 
> > What do you mean by "has no option for mode to select"? Tunable allows
> > you to select any mode. And unless mode is off, I don't see any issue
> > here.
> 
> Right, so the tunable enables 'heap' tagging for unmarked binaries *and*
> selects the mode for marked ones.

Not exactly. Like I said above, the tunable signals that "standard"
tagging should be enabled and tells which mode should be used for that.

At the moment "standard" would include malloc but it can be extended in
the future.

Users will have 2 options:

1) Use unmarked binaries and use "standard" scope with any of the
   supported modes.

2) Use marked binaries that contain required configuration in the
   binary marking. As you suggested, in this case tunable will have
   no effect on the scope or mode.

Note that the idea of "standard" scope for memory tagging reflects the
idea behind having a "standard" branch protection option in GCC which
includes everything that is reasonable to include for general purpose
use cases and the set of included elements may vary from release to
release.

> I think this works where only heap
> tagging have this implicit setup, but it does not give us much room to
> extend it (say we want to add opt-in MTE support for a different feature,
> and it rules out the opt-in MTE stack/global enablement).

If users of **unmarked binaries** need more control over what parts of
the "standard" memory tagging is enabled or disabled, we can always add
another tunable for this later, we don't have to do it now. I'd rather
not do it now. All I want to do now is to make sure we don't block any
future extension, and with my approach we don't.

> And most of projects using MTE are allocators or indirectly using 
> compiler instrumentation, so adding extensibility does not seems a pressing
> issue either.

I'm not sure I understand this statement. It seems incorrect to me. Our goal
is to allow users to enable memory tagging protection for any programs they
choose. I think it's important to understand that what I'm working on is not
limited to a few particular use cases. I'd like to support any specific things
as well as allow broad usage of memory tagging with minimal configuration
effort.

Regards,
Yury