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

[Adhemerval Zanella Netto]

On 16/06/25 12:39, Florian Weimer wrote:
> * Yury Khrustalev:
> 
>> On Mon, Jun 16, 2025 at 03:56:10PM +0200, Florian Weimer wrote:
>>> * Yury Khrustalev:
>>>
>>>> Call __libc_arm_za_disable before syscall to clear ZA state of SME for the
>>>> clone and clone3 syscalls.
>>>
>>> These system calls are frequently called through general syscall wrapper
>>> function.  Doesn't that have to be fixed as well?
>>
>> As far as I know, there isn't any use of syscall(__NR_clone, ...) or
>> syscall (__NR_clone3, ...) in the Glibc (or any SVC in assembly that
>> would use either of these syscall numbers).
>>
>> Userspace should ideally use the clone() function that is part of the
>> Glibc API.  In case of clone3() there is no such public function.
> 
> Using clone often requires writing a callback function and longjmp'ing
> out of it.  Of course, the syscall function only works for fork-style
> clone, not for vfork-style and not for thread-style.
> 
>> Any direct syscall is regarded as sufficiently low level, and we presume that
>> those who do that already know what they are doing and they would have to do
>> all the required ABI-related preparations.
> 
> I don't think this assumption is correct.  Fork-style clone is
> reasonably portable today, so it's used in quite a few places:
> 
>   <https://codesearch.debian.net/search?q=syscall.*(NR%7CSYS)_clone&literal=0>

There is another indication that this should be at least proper documented
on Documentation/arch/arm64/sme.rst to indicate which flags or argument
usage are not properly handled by the kernel, along with the requirement to
clear the ZA state before clone/clone3.  This extra constraint also
apply not only for C, but on all other runtimes that issues syscalls directly
(for instance golang, other libcs, sanitizer, etc.).

But again, I am still not fully convinced that userland should be the one
taking care of this.  As Rich has put in this email, the task creation and
the expansion set of register state consistency should be delegated to the
kernel.

Also, Linux v6.16 (cde5c32db55740659fca6) patch description states that
all internal glibc usages of clone/clone3 are not affected; so the ZA state
clear should only be add on the *external* clone interface.