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

[Yury Khrustalev]

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.

> 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).