On memory tagging status in Glibc

[Adhemerval Zanella Netto]

On 18/03/26 11:43, Yury Khrustalev wrote:
> 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.

The DT_AARCH64_MEMTAG_GLOBALS handling here is not to *support* tagging the
memory but rather check if the binary has DT_AARCH64_MEMTAG_GLOBALS present
to indicate that the process can not run because missing ld.so support.

And this is not for preliminary --enable-memory-tagging cleanup, but rather
for the DT_AARCH64_MEMTAG_STACK support.

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

It would be similar to GLIBC_ABI_DT_RELR added by -z pack-relative-relocs. If
-z memtag-stack is present and during the linking phase, ld inspects the linked
shared libraries to see if the C library provides a GLIBC_2.* symbol version.

If the GLIBC_2.* version node is found, the linker artificially injects 
GLIBC_ABI_MEMTAG as a required version dependency. This dependency is written 
into the resulting ELF binary's .gnu.version_r (Version Needs) section.

Because of this injected dependency, the resulting ELF file strictly requires 
a glibc runtime that exports GLIBC_ABI_MEMTAG, guarding against SIGILL failures
on legacy systems that might happen any time during process execution.

On glibc side we will need to add the GLIBC_ABI_MEMTAG on elf/dl-version.c
if/when DT_AARCH64_MEMTAG_* is added.  I do not think we should add an
ABI tag for each support features (global/stack/heap/mode), aborting process
execution for a missing feature is suffice to proper handle compatibility.

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