On memory tagging status in Glibc

[Adhemerval Zanella Netto]

On 18/03/26 06:43, Yury Khrustalev wrote:
> Hi,
> 
> Just to summarise status of the "Enable MTE support for stack" patch [1].
> 
> There have been a number of points raised in the comments in that thread,
> however, the overall picture is that some preparation needs to be done before
> this patch can move forward.
> 
> [1]: https://inbox.sourceware.org/libc-alpha/20260310141107.43347-1-claudiu.zissulescu-ianculescu@oracle.com/
> 
> I am working on a separate patch for this preparation right now.
> 
> 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).

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

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

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. 

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.
> 
> Before we make the prctl syscall we need to do 2 things:
> 
> 1) Check HWCAP2_MTE: this happens in init_cpu_features.
>    Note that the glibc.mem.tagging tunable will need to be processed here
>    too. This tunable will change as well, and later we will need to figure
>    out how to merge value of this tunable with whatever ELF marking we will
>    also use.
> > 2) Scan binaries for dynamic array tags or program properties (or whatever)
>    and determine flags for the prctl syscall: this happens in _rtld_main_check.
>    Note that the check function should also be called for dlopen, however it's
>    up for a discussion what to do at that point.
> 
> There will be two macros USE_MTAG_HEAP and USE_MTAG_STACK that should be used
> to guard code that only needs to be compiled when corresponding configure option
> is selected.
> 
> The --enable-memory-tagging flag will take a comma-delimited list of types of
> memory tagging, e.g. --enable-memory-tagging=stack,heap. By default, the value
> is none.
> 
> My plan is to eventually change the default value for aarch64 to heap when the
> implementation of tagging in malloc is ready.
> 
> 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.

> 
> Hope this helps,
> Yury
>