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

[enh]

On Mon, Jun 9, 2025 at 8:51 AM Mark Rutland <mark.rutland@arm.com> 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.

...but then wouldn't bionic need similar changes, for its clone()?

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