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

[Yury Khrustalev]

*  Adhemerval

On Fri, Mar 13, 2026 at 03:51:10PM -0300, 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.
> 
> For 1. dlopen requires failing similarly to how we do for GCS. The 2. 
> is technically possible, but implementing it properly requires either 
> stop-the-work mode (as sanitizers use with ptrace) or some synchronization 
> between pthread_create and dlopen to change all thread stacks during 
> process execution without any thread or dlopen altering the global 
> thread state. 
> 
> Android does something like that [1] (with 
> __pthread_internal_remap_stack_with_mte), with a global lock for 
> pthread/dlopen. I am not sure if we should follow the same semantics.
> 
> [1] https://android.googlesource.com/platform/bionic/+/main/docs/mte.md

Hi Adhemerval, thanks for this input, you raise important points here
but I think you've misunderstood my point entirely here.

Ideally, there should be no --enable-memory-tagging configure option
(and right now we're looking into the best way to remove it) and as for
the glibc.mem.tagging tunable, it should either be gone or do something
else.

The 2nd patch in this series misuses the --enable-memory-tagging configure
option without offering a clear path to separately controlling stack and
heap tagging. I think this is not going to work well.

The question that you are raising above is important one but it is out
of scope here.

Thanks,
Yury