[PATCH v3 1/2] rtld: Enable MTE for stack when specified in .dynamic

[Adhemerval Zanella Netto]

On 13/03/26 15:51, Adhemerval Zanella Netto wrote:
> 
> 
> On 11/03/26 07:36, Yury Khrustalev wrote:
>> On Tue, Mar 10, 2026 at 04:11:06PM +0200, claudiu.zissulescu-ianculescu@oracle.com wrote:
>>> From: Cupertino Miranda <cupertino.miranda@oracle.com>
>>>
>>> This patch enables Memory Tag Extension (MTE) for stack tagging in the
>>> rtld. Parse DT_AARCH64_MEMTAG_STACK and DT_AARCH64_MEMTAG_MODE from
>>> the main program and enable stack memory tagging in the dynamic
>>> loader, as described in ARM's ABI [1] documentation.
>>>
>>> Ref:
>>> [1] https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst
>>> ---
>>>  elf/elf.h                                     |  7 +-
>>>  sysdeps/aarch64/Makefile                      |  1 +
>>>  sysdeps/aarch64/cpu-features.h                | 12 +++
>>>  sysdeps/aarch64/dl-mte.c                      | 85 +++++++++++++++++++
>>>  sysdeps/aarch64/dl-prop.h                     |  4 +
>>>  sysdeps/unix/sysv/linux/aarch64/Makefile      |  4 +
>>>  .../unix/sysv/linux/aarch64/dl-mte-stack.c    | 45 ++++++++++
>>>  7 files changed, 157 insertions(+), 1 deletion(-)
>>>  create mode 100644 sysdeps/aarch64/dl-mte.c
>>>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/dl-mte-stack.c
>>>
>>
>> This patch should have at least one test checking that the added
>> functionality works as intended for each supported mode of stack
>> tagging. Ideally, we should check both statically-linked and
>> dynamically-linked cases.
>>
>> Some notes below. In a nutshell, I think this experimental functionality
>> should be hidden behind a configure flag or at least a tunable.
>>
>> Note that there already is a configure flag "--enable-memory-tagging"
>> which adds -DUSE_MTAG macro and unlock heap tagging in malloc which is
>> why it's probably not a good idea to use the same guard for stack
>> tagging.
>>
>> Whatever way to disable stack tagging is chosen, it should somehow
>> co-exist with the "--enable-memory-tagging" configure flag and the
>> corresponding tunable "glibc.mem.tagging". Both of these two things
>> may change soon to make memory tagging in malloc more usable. For this
>> reason I would encourage a conversation about how these two things
>> (tagging of heap and stack) can be controlled independently.
>>
> 
> It does not make sense to add a tunable for DT_AARCH64_MEMTAG_STACK, 
> and, given that this is an opt-in feature, I am also not sure whether 
> adding a configure check would be really worth it here.
> 
> A binary with DT_AARCH64_MEMTAG_STACK has text segments that always 
> use MTE instruction, so running them on hardware without HWCAP2_MTE 
> is expected to trigger SIGILL (with exceptions for possible 
> misconfigured environments like qemu with -cpu max and -m virt,mte=off, 
> and I am not sure how proper hardware is supported to work when MTE 
> is not enabled by the kernel).
> 
> So, the most sensible behavior from the loader standpoint is to abort
> startup with a proper error if DT_AARCH64_MEMTAG_STACK is present and 
> the kernel does not support HWCAP2_MTE. A tunable will only mask this 
> off and not prevent the SIGILL.
> 
> The --enable-memory-tagging option differs because glibc can control 
> whether to tag memory (sysdeps/aarch64/libc-mtag.h), so it malloc can 
> be used on hardware without MTE support. I would expect that 
> DT_AARCH64_MEMTAG_HEAP would enforce its usage.
> 
> And I think we also need to define how DT_AARCH64_MEMTAG_STACK will 
> play along with dlopen. The current approach will:
> 
>   1. On hardware without MTE, triggers a SIGILL when a binary without 
>      MEMTAG_STACK dlopen a library with MEMTAG_STACK
> 
>   2. On hardware with MTE, dlopen a MTE will succeed without enabling 
>      MTE on the stack.

Beside these points, I think we need to sort other missing semantics:

3. How should glibc handle other DT_AARCH64_MEMTAG_* with only 
   DT_AARCH64_MEMTAG_STACK support? Should we just ignore (and allowing 
   possible SIGILL during process execution) or should abort at process
   startup (fail early)? Same for dlopen case for 1. and 2.

4. How should audit/DT_AUDIT module should act wrt DT_AARCH64_MEMTAG_*? 
   They are loaded before the main program and it might require to either 
   always enable MTE or fail if process does not have the Memtag ABI.

5. Same as 4. but for preload/LD_PRELOAD.

6. How should have running binaries with DT_AARCH64_MEMTAG_* on old
   glibc releases? For DT_RELR we ended up adding a glibc specific symbol
   version (GLIBC_ABI_DT_RELR), and I think we should also consider doing
   the same here.