On memory tagging status in Glibc

[Yury Khrustalev]

On Wed, Mar 18, 2026 at 11:07:57AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 18/03/26 06:43, Yury Khrustalev wrote:
> >
> > ...
> >
> > In a nutshell, we need to change configure flag --enable-memory-tagging to
> > allow for two independent macros for heap and stack tagging activated based
> > on the value of this flag. Furthermore, we need to change how prctl syscall
> > is made to enable PR_SET_TAGGED_ADDR_CTRL. There has to be only one place
> > where this happens that should work for both stack and heap tagging.
> 
> I think extending --enable-memory-tagging adds build permutations that will 
> require extra build/testing and, from previous experience, it would become 
> bit-rotten over time (as --enable-memory-tagging already shows when running 
> in an environment with MTE support).

I agree with that. My original plan was to remove this configure flag
entirely and implement automatic runtime setup. However, this requires
much deeper refactoring of many places. If I have time for that, I'm
happy to do it, but it will inevitably delay the MTE support for stack
work. We can probably remove --enable-memory-tagging later. Using it for
now is not making things worse than they already are.

> >From my previous remarks I see that adding support for DT_AARCH64_MEMTAG_STACK 
> without also proper handling all DT_AARCH64_MEMTAG_* tags is inconsistent and 
> might resulting in binaries that might fail at runtime.

I just want to note that any support for DT_AARCH64_MEMTAG_* is out of
scope of this preparation work.

> For the proposed DT_AARCH64_MEMTAG_STACK support, I would expect that if 
> DT_AARCH64_MEMTAG_GLOBALS is present, the process would abort during startup. 

...especially DT_AARCH64_MEMTAG_GLOBALS is way out of scope.

> Similar for DT_AARCH64_MEMTAG_HEAP if !USE_MTAG. It will handle running binaries
> that might eventually implement DT_AARCH64_MEMTAG_GLOBALS on old glibc.

Ditto

> And I 
> still think we should add a synthetic symbol version on Memtag ABI built for 
> the GNU ecosystem, similar to how we did for DT_RELR.

Please write up the details of this if you have time. Again, this is out
of scope of the work I've highlighted above.

> So it makes sense to me gate all Memtag support on --enable-memory-tagging, 
> including DT_AARCH64_MEMTAG_* and malloc support. The malloc code will continue 
> to allow enablement independently of Memtag's dynamic tag presence, and it will 
> simplify the required internal definitions and testing.

Memtag's dynamic tags are merely a way to configure runtime. Their
effect is the same as effect of tunables.

> The configure flag is optional, and we could document that the ABI might change
> if Memtag does. We already added conditional ABI support with —enable-cet on Intel, 
> so this is not new.

OK

> > 
> > ...
> >
> > The glibc.mem.tagging tunable will be changed to be an enum and it will be used
> > to select the mode of tagging: none, auto, sync, async. If tunable is provided,
> > we do prctl syscall PR_SET_TAGGED_ADDR_CTRL with the selected mode (unless it is
> > overridden based on ELF marking, subject to discussion).
> 
> I think if the binary has DT_AARCH64_MEMTAG_* it should take precedence over
> the tunable.

I disagree, but again this is off-topic.