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

[Adhemerval Zanella Netto]

On 16/03/26 11:32, Yury Khrustalev wrote:
> On Mon, Mar 16, 2026 at 11:19:20AM -0300, Adhemerval Zanella Netto wrote:
>>>>>
>>>>> ...
>>>>>
>>>>> 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.
> 
> I hear you, but I disagree, however this is not in this scope, let's
> discuss it elsewhere.
> 
>> If we really
>> do not want to commit to the current AArch64 Memtag ABI,
> 
> We really cannot: that ABI has been ALPHA which means it's unstable and
> is subject to change.

It is not clear to me exactly what you think we not commit wrt current 
AArch64 Memtag ABI.  Both gcc and clang support DT_AARCH64_MEMTAG_* for a
while, and even Memtag ABI Extension is not fully clear about all runtime
behavior compile support is ready and current definitions are reasonable. 

For DT_AARCH64_MEMTAG_STACK it defines that:

  "If DT_AARCH64_MEMTAG_STACK is present, the dynamic loader should enable 
   tagging for the main stack and thread stacks. Re-mapping currently alive 
   stack frames as taggable is dangerous."

I tend to agree with this and I think we should *not* follow Android that
allows stack remapping during process execution.

There is an extra care for audit modules and ldproload modules, since they
are loaded *before* executable dynamic tags parsing that we will require
extra care.

> 
>> best course of
>> action is to add a configure check (--enable-experimental-memtag or
>> something), that enables the handling of DT_AARCH64_MEMTAG_*.
> 
> I'm happy to consider that, but DT_AARCH64_MEMTAG_* includes not only
> stack but also heap, globals, and so on. If we make a point of
> implementing this ABI (even if under an "experimental" flag), we should
> implement it consistently.
> 
> Furthermore, if we look at the dynamic array tags, question is, what do
> we do with static binaries? We already have GNU properties for other
> features, so it might be reasonable to do the same for memory tagging.
> Which means we should not really support DT_AARCH64_MEMTAG_* in Glibc at
> all (not even experimentally).
> 
> We should discuss all these questions, come to some consensus and then
> come back to this patch (or rather its updated version).
> 
>