aarch64: Memory tagging modes proposal

[Adhemerval Zanella Netto]

On 01/09/26 12:16, Yury Khrustalev wrote:
> 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.

There is a potential issue with this approach, where if we don't specify
what 'standard' means for future extensions we might add subtle breakage.
For instance, if the system has the MTE tunable for binary and the glibc in
future release extends this where it potentially triggers some invalid
usage (due binary not being properly tested or having a latent issue).
This can be really annoying for system tunables, where it can lead of an
unstable system.

This is different than compiler options, where it is baked in the binary
and with a defined semantic. If user want to use a new hardened features
it should opt-in with a rebuild.

That's why I think having 'auto' enabling malloc tagging is somewhat
confusing. I would prefer to have a more descriptive name and maybe disassociate
with the MTE mode.

> 
>> 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.
My point is now MTE seems to be used more on malloc hardening projects, not
that MTE should or can be used only for this.