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

[Yury Khrustalev]

Hi,

On Mon, Sep 22, 2025 at 03:16:01PM -0400, enh wrote:
> On Fri, Sep 19, 2025 at 5:09 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
> > ...
> > I hope that the explanation provided in the commit message in this patch
> > addresses the questions raised earlier. So far, there was one adjacent
> > question about making clone3() public. Can I ask if you have any further
> > concerns or questions from the point of view of bionic or musl? I'd like
> > to go ahead with this patch, if not.
> 
> i think the "make clone3() public" question is orthogonal.

That is my thinking as well, so we probably should continue this
discussion elsewhere.

> ...

> it still seems to me like the commit message here, specifically
> 
> > However, in certain cases, the kernel may ensure that a "child" doesn't
> > start in an incorrect state. This is what is done by the recent change
> > included in 6.16 kernel [5]. This is not enough to ensure that code that
> > uses clone() and clone3() function conforms to [1] when it runs on a
> > system that provides SME, hence this change.
> 
> conflicts with the commit message [5], specifically the last clause of
> the last sentence of
> 
> > Ideally we'd require that userspace ensures that a task is in the "ZA
> > off" state (with PSTATE.ZA==0 and TPIDR2_EL0==NULL) prior to issuing a
> > clone syscall, and have the kernel force this state for new threads.
> > Unfortunately, contemporary C libraries do not do this, and simply
> > forcing this state within the implementation of clone would break
> > fork().
> 
> ?

There are several things here:

1) "forcing" in [5] (kernel patch) means ONLY setting registers without
saving the state as opposed to graceful change done by userspace when
it calls __arm_za_disable(). Kernel cannot call __arm_za_disable().
I have tried to explain the details in:
https://inbox.sourceware.org/libc-alpha/aGLIp1errIlQYSkM@arm.com/

2) Specifically for fork(), it is important to make sure that when the
child is created, it has consistent copy of memory of its parent. If we
mess up with ZA state for the child and not for the parent (again,
kernel would not change parent's state here), the "copy" would be
inconsistent.

3) That is why it is much easier to do this extra step on the userspace
side and before invoking the SYS_clone syscall: (a) we do all necessary
steps, and (b) we make sure that parent's state is OK before it is
copied into child's state.

So, there is no contradiction here.

> (also it's been long enough since this last came up that i've
> forgotten why there isn't the corresponding bionic clone() change...)

AFAIK, the plan was to send corresponding patch for bionic, but since
the discussion around Glibc patch has been going on, this plan was
postponed.

Thanks,
Yury