aarch64: Memory tagging modes proposal

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Thu Aug 27 21:08:27 GMT 2026



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.  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).

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

> 
>> , it will
>> always need to use the kernel default.
> 
> Nobody has to use kernel default mode unless they want to. Choose
> tunable value that works for your use case and use it.



More information about the Libc-alpha mailing list