[PATCH v3 1/2] rtld: Enable MTE for stack when specified in .dynamic
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Mon Mar 16 13:31:56 GMT 2026
On 16/03/26 06:06, Yury Khrustalev wrote:
> * 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.
I understood that you suggested adding another tunable for Memtag ABI
extension [1], but it seems that I misunderstood.
And I agree that it is time to remove --enable-memory-tagging, and I think
that it has not been done yet because not widely available MTE hardware
support (1), and there is still a minor performance impact when USE_MTAG is
defined (a global variable load plus comparison) (2).
We are starting to see some hardware with MTE support, and qemu now has full
support, so 1. should not be a problem for allowing more testing. I also do
not consider (2) to be an impending issue, although it would be good to have
some performance numbers to know the impact, because memtag changes how malloc
works (it will make __glibc_morecore fallback to mmap more often to allow more
memory to be tagged).
And to enable --enable-memory-tagging we definitely need more testing, since
this is not enabled by default, nor do we have tests that explicitly check the
tunable.
And running a simple test shows that we need to fix some issues before actually
enabling it by default:
$ cat t.c
#include <stdlib.h>
#include <string.h>
int main ()
{
const size_t sz = 128;
void *h = malloc (sz);
memset (h, 0xaa, sz);
free (h);
}
$ gdb -ex "set env GLIBC_TUNABLES=glibc.mem.tagging=1" --args elf/ld.so --library-path . ./t
[...]
(gdb) r
Starting program: /home/azanella/Projects/glibc/build/aarch64-linux-gnu/elf/ld.so --library-path . ./t
warning: Expected absolute pathname for libpthread in the inferior, but got ./libc.so.6.
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
Program received signal SIGSEGV, Segmentation fault
Memory tag violation
Fault address unavailable.
__unregister_atfork (dso_handle=dso_handle@entry=0xfffff7fa0040) at register-atfork.c:83
83 lll_lock (atfork_lock, LLL_PRIVATE);
(gdb) bt
#0 __unregister_atfork (dso_handle=dso_handle@entry=0xfffff7fa0040) at register-atfork.c:83
#1 0x0000fffff7dfddac in __cxa_finalize (d=0xfffff7fa0040) at cxa_finalize.c:120
#2 0x0000fffff7f80800 [PAC] in ?? ()
#3 0x002dfffff7e5cd08 in ?? ()
We made multiple changes to the generic malloc code, and I think memory
tagging support might have been regressed due to insufficient testing.
>
> The question that you are raising above is important one but it is out
> of scope here.
>
> Thanks,
> Yury
>
[1] https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst
More information about the Libc-alpha
mailing list