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

[Andrei Vagin]

On Fri, Aug 7, 2026 at 8:05 PM Chang S. Bae <chang.seok.bae@xxxxxxxxx> wrote:
>
> On 8/7/2026 4:12 PM, Andrei Vagin wrote:
> >
> > 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).
>
> https://docs.kernel.org/arch/x86/xstate.html
>
> -ARCH_GET_XCOMP_SUPP
> arch_prctl(ARCH_GET_XCOMP_SUPP, &features);
>
> ARCH_GET_XCOMP_SUPP stores the supported features in userspace storage
> of type uint64_t. The second argument is a pointer to that storage.
>
> -ARCH_GET_XCOMP_PERM
> arch_prctl(ARCH_GET_XCOMP_PERM, &features);
>
> ARCH_GET_XCOMP_PERM stores the features for which the userspace process
> has permission in userspace storage of type uint64_t. The second
> argument is a pointer to that storage.
>
> Do you need something else than these?

If we decide not to enable dynamic features when restoring state from a
signal frame:

diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 083f03d2d002..e2eeb85cc0cd 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -64,6 +64,9 @@ static inline bool check_xstate_in_sigframe(struct
fxregs_state __user *buf_fx,
        if (unlikely(magic2 != FP_XSTATE_MAGIC2))
                goto err_setfx;

+       if ((fx_sw->xfeatures & XFEATURE_MASK_USER_DYNAMIC) &
~fpstate->user_xfeatures)
+               return false;
+
        if (fx_sw->xstate_size != fpstate->user_size ||
            fx_sw->xfeatures != fpstate->user_xfeatures) {
                unsigned int xsize;


Then when a process is restored, we need to re-enable all dynamic
features that were enabled at the time of dump (restoring
fpstate->user_xfeatures per thread).

However, ARCH_GET_XCOMP_PERM only gives us the mask of permitted
features for the process, not what is actually enabled for each thread.
We could blindly enable all permitted features on all threads, but that
is not ideal.

Thanks,
Andrei