[PATCH v2] rtld: Enable MTE for stack when specified in .dynamic

[Cupertino Miranda]

On 25-02-2026 6:05 PM, Yury Khrustalev wrote:
> On Wed, Feb 25, 2026 at 05:29:42PM +0000, Cupertino Miranda wrote:
>> Hi Yury,
>>
>> Can you please detail some more what are you working on.
> 
> We look at heap allocations so it will touch the part that implements
> memory tagging in malloc. Ideally, we'd like to have some uniformity in
> configuration of Glibc's use of memory tags. E.g. there is a tunable
> that is supposed to control malloc use of memory tags (glibc.mem.tagging)
> and you use dynamic array tags in binaries which seem like a good option
> but we probably need to use only one mechanism. I'll take a closer look
> at your patches tomorrow.
For stack MTE stack protection, it should be some flag coming from the 
executable and not a tunable alone. Only if the executable was compiled 
with stack protection code it actually should enable stack MTE.
> 
>> Please notice that my changes in GLibc in respect to MTE are in sync with
>> the work from Claudiu (in cc as well), which is already upstreamed to GCC.
> 
> You and Claudiu seem to have followed the mem tag ABI [1] which
> probably requires some kernel work that hasn't been done yet to
> properly allow Glibc to deal with stack protection, though I need
> to check this further.
We did indeed followed [1].

 From the kernel side, I think we just need to have prctl/mprotect, 
support for MTE, and to be able to verify that the hardware supports MTE.

I don't think there is a need for any other kernel support since the 
purpose is not to enable stack MTE for the kernel but user level 
applications.
So far in my experiments calling mprotect, enabling MTE for the current 
stack page seems to be doing the proper job. The kernel seems to be 
copying the same prot flags in the newer stack pages, when the stack 
needs to grow.
> 
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2025-November/699675.html
>>
>> Looking forward to your reply.
> 
> I found two patch series so far [2] and [3]. Are those the latest
> versions? Any other patches that I missed? These are pretty old,
> do you plan to rebased and send newer versions any time soon? I can
> review [2] and [3] otherwise.

We will be sending a new version soon enough. It will likely be 
submitted by Claudiu together with a new patch to properly clear MTE 
coloring on the stack for setjmp/longjmp.

> 
> I'm not sure how this never came up during any of the patch
> review calls... Please do CC someone from Arm when you change
> code specific to an Arm target.
I think I did mention it in the patchwork meeting, but not so recently, 
since I am currently not really focusing in any glibc work. :(
We will CC you and Wilco in any upcoming patches for MTE.

Thanks,
Cupertino


> 
> ---
> 
> [1]: https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst
> [2]: https://patchwork.sourceware.org/project/glibc/list/?series=51446
> [3]: https://patchwork.sourceware.org/project/glibc/list/?series=45014
> 
> Thanks,
> Yury
>