Re: [PATCH 09/10] x86/fpu: Allow restoring signal frames with larger xstate_size

On Fri, Aug 7, 2026 at 8:56 AM Chang S. Bae <[email protected]> wrote:
>
> On 8/4/2026 1:30 PM, Andrei Vagin wrote:
> >
> > We can do something like this in check_xstate_in_sigframe():
> > unenabled = fx_sw->xfeatures & ~fpstate->user_xfeatures;
> > unenabled &= xstate_get_host_group_perm() & XFEATURE_MASK_USER_DYNAMIC;
> > if (unenabled) {
> >          if (xfd_enable_feature(unenabled))
> >                  return false;
> >          fpstate = x86_task_fpu(current)->fpstate;
> > }
> The inner function __xfd_enable_feature() is currently invoked from two
> spots: (1) the #NM handler on the first userspace touch of a dynamic
> state, and (2) VCPU allocation when creating an AMX-enabled VM.
>
> For the latter, this was a chosen approach for the simplest AFAIK. Along
> with the same lines, the ptracer path deliberately does _not_ expand a
> ptracee's dynamic state.
>
> I would expect ptrace to be the first place to adopt such an expanding
> context injection. I'm not suggesting it at all; rather, the fact that
> ptrace does not do such suggests there has been a conscious effort to
> avoid adding complexity around XFD/dynamic-state management.
>
> Given that, it looks less convincing without first demonstrating that
> this cannot be handled in userspace. More importantly, since this would
> introduce yet another way for expanding the XSAVE buffer, it deserves
> auditing possible side-effects.

We definitely can trigger enablement of dynamic features from
user-space, but the issue is that userspace currently has no way to
query what features are actually enabled for a task (the kernel only
exposes fpstate->user_xfeatures through signal frames, which is not
viable for C/R). We can consider exposing this information via
arch_prctl or ptrace, but I think it is better to do that outside of
this patchset. To keep this patchset simple, I suggest we explicitly
reject signal frames that contain dynamic features not yet enabled for
the current task.

Thanks,
Andrei