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

[Adhemerval Zanella Netto]

On 16/03/26 11:08, Yury Khrustalev wrote:
> On Mon, Mar 16, 2026 at 10:31:56AM -0300, Adhemerval Zanella Netto wrote:
>>
>> 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.
>>>>>
>>>>
>>>> ...
>>>>
>>>> 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.
> 
> I was just saying we need some form for control over when the proposed
> stack tagging is enabled. There is no *defined* ABI for stack tagging, so
> it either have to be done in a way that doesn't require any Glibc changes
> or we have to make it disabled by default and only enabled on demand and
> explicitly.
> 
> Whether to use configure flag or tunable or something else, we can
> consider various options.

As I said the tunable does not make sense in this context.  If we really
do not want to commit to the current AArch64 Memtag ABI, best course of
action is to add a configure check (--enable-experimental-memtag or
something), that enables the handling of DT_AARCH64_MEMTAG_*.

It seems that Android already is implement is as non-experimental, and
it moves from the system specific .note.android.memtag to the Memtag
in recent versions.

> 
>> 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).
> 
> I am working on this right now, but it's not an easy thing to do. We
> certainly don't want to just delete #ifdef USE_MTAG, it has to be more
> tricky than that.
> 
>> 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:
>>
>>
>> ...
>>
>> We made multiple changes to the generic malloc code, and I think memory 
>> tagging support might have been regressed due to insufficient testing.
> 
> Exactly, and sorting this out will require some work. Adding support for
> stack tagging should not be just bolted on the existing code. It should
> either be entirely independent of the malloc part (including things like
> USE_MTAG) or it would have to wait till existing code has been
> refactored and under regular testing.

I agree and my previous comments are not really for this part.