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

[Mark Rutland]

On Mon, Jun 09, 2025 at 05:36:20PM -0300, Adhemerval Zanella Netto wrote:
> On 09/06/25 09:51, Mark Rutland wrote:
> > 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?

It means that the feature is completely disabled, and the relevant
kernel code cannot be built unless someone manually hacked up the kernel
source code (specifically, the Kconfig file, which defines the set of
configuration options which are available).

>From userspace's PoV, on kernels where SME is marked as BROKEN, SME is
not present (and e.g. HWCAP2_SME will not be set). It should appear the
same as running on hardware that lacks SME.

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

I agree that on kernels without the BROKEN marking, SME is not usable.
Note that the patch to mark SME as BROKEN was backported to the stable
kernel branches (which distributions take fixes from). The plan is that
SME will not be re-enabled on those patches without backporting all the
relevant fixes.

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

For kernels where SME is marked as BROKEN, you don't need to do
anything. It looks the same as if SME is simply not present.

For kernels with the broken support, but lacking the backport of the
BROKEN marking, I don't think you need to care. IIUC we agree on that?

Mark.