[PATCH v2 0/1] aarch64: clear ZA state of SME before clone and clone3

[Yury Khrustalev]

Hi everyone,

** Rich,

On Mon, Jun 30, 2025 at 03:43:27PM -0400, Rich Felker wrote:
> On Mon, Jun 30, 2025 at 06:27:44PM +0100, Yury Khrustalev wrote:
> ...
> > > I have not heard any good reason. This is my position too. Libc must
> > > not be required to do anything here, because the user could be using a
> > > libc older than the kernel and older than the application that's using
> > > the new register file. The kernel which adds support for expanded
> > > register file is *always*, *100%* responsible for doing whatever is
> > > needed to make the addition of the new register file non-ABI-breaking.
> > > And in the case of this stuff, that includes performing the
> > > lazy-save-and-clear at *all* fork/clone operations, kernel-side.
> > 
> > There are limits to what kernel can do compared to userspace. In userspace,
> > we can call __arm_za_disable() (see section about this function in [1])
> > but we can't do this on the kernel side. This function does 3 things:
> > 
> >  (a) Save ZA buffer by calling __arm_tpidr2_save() (see [1])
> >  (b) Set TPIDR2_EL0 to null
> >  (c) Set PSTATE.ZA to 0
> > 
> > and the kernel can only do the last 2 things (b) and (c) because it never reads
> > or writes the ZA save buffer and it never uses the contents of TPIDR2 directly.
> 
> That's a matter of policy choice, not "can't". The kernel absolutely
> can do what's in the body of __arm_tpidr2_save, namely loading the
> address of the save buffer from TPIDR2_EL0 and dumping the register
> file at that location.

I think that a mere technical possibility for the kernel to do something is not
a valid justification for assigning the responsibility for this to the kernel.

I guess we could call it a "policy choice" but there are reasons for this
"policy" and we shouldn't consider changing it here.

JFYI, a similar situation exists with setjmp() and longjmp() where we ought to deal
with the consistency of the ZA save buffer on the userspace side (see [1,2]) and
the kernel is not involved here.

Working with ZA save buffer from the kernel is incorrect and may corrupt userspace
memory and it would also lead to unnecessary coupling of the current version of ABI
into the kernel syscall interface. The ABI related to ZA state of SME could be extended
in the future, and this won't play well with the kernel having to deal with all the changes.

So far I haven't seen any compelling reason not to proceed with this change. I think
I and my colleagues have provided enough justification at this point.

[1]: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a7373e457f0b5953d230f7756627036b1711dcc3
[2]: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a7f6fd976c17b82dc198290b4ab7087f35855a0e

Thanks,
Yury