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

[Mark Rutland]

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.

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.

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

Does that make sense to you?

Mark.