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