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

[Adhemerval Zanella Netto]

On 09/06/25 09:51, Mark Rutland wrote:
> Hi Elliott,
> 
> On Mon, Jun 09, 2025 at 08:16:46AM -0400, enh wrote:
>> was there an answer to my earlier question of "if this was fixed in
>> the kernel, and there are no released kernels that have SME support
>> but don't have this fix, why would we have a workaround?".
> 
> Sorry; Yury had asked me to respond regarding this, but I had been busy
> elsewhere.
> 
> The gist is that what the kernel now does is sufficient for typical libc
> usage of clone(), for fork() and pthread_create() specifically (and IIUC
> that's good enough for bionic), but we're not sure whether there's any
> userspace usage of clone() that uses CLONE_* flags in a different
> manner (e.g. via wrappers exposed from glibc). This is intended to
> ensure that any such cases don't encounter problems.
> 
> The longer history is:
> 
> 1) Linux v5.19 (2022-07-31) released with SME support. This had a number
>    of severe issues that had not been identified at the time, and there
>    was no SME-capable HW available at the time of release.
> 
> 2) Linux v6.12 (2024-11-17) marked SME as BROKEN once the severe issues
>    were identified. That happened in commit:
> 
>    81235ae0c846 ("arm64: Kconfig: Make SME depend on BROKEN for now")
> 
>    ... which was backported to all upstream stable trees. I believe that
>    landed in the android common kernel and distribution kernels.

What does 'BROKEN' mean? Is that the SME enablement option will be hidden
without some additional non-default option?

> 
> 3) While fixing the issues mentioned above, additional ABI issues with
>    setjmp()+longjmp() and clone() were identified. The
>    setjmp()+longjmp() isues were fixed with userspace saving state in
>    setjmp().
> 
>    The original plan was to have userspace do the same for clone(), as
>    the kernel cannot handle this safely in all cases.
> 
>    The kernel behaviour for fork() is a bodge that we know is sufficient
>    for extant usage  of clone() to implement fork() and
>    pthread_create(), but we don't know is safe for all potential uses of
>    clone().
> 
> 4) The fixes (including the clone() bodge) were merged for v6.16 (to be
>    released), and backported to the android v6.12 tree. I intend to
>    backport the SME re-enablement back to upstream v6.12, but no earlier.

So what is the SME status between v5.19 and v6.12? Because 81235ae0c846
'corrupt the FPSIMD/SVE/SME state of arbitrary tasks' seems really bad and
make it SME unusable.

> 
> Practically speaking, I don't think glibc needs to care about kernels
> without the SME fixes. If those haven't received a backport of the patch
> marking SME as BROKEN, they are already in a severely broken state (e.g.
> with signal handlers triggering random crashes, and userspace able to
> trivially cause a kernel panic).

So if I understood correctly, these changes alone in userland to clear
ZA state prior clone class is not really suffice on a system that advertise
HWCAP2_SME without further patches that we merged only for v6.16.

To summarize, and correct me if I am wrong, from v5.19 to v6.12 SME is 
unusable due the state corruption, and from v6.12 to v6.16 is disable by
default (due BROKEN).  So the question is whether we should handle 
BROKEN configuration and/or old kernel with broken support; and my 
suggestion is we should not care as well.

The tests, in the other hand, seems to be a good addition and it would be
useful to check for regressions.

> > Does that make sense to you?
> 
> Mark.