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

On Fri, Jul 31, 2026 at 5:49 PM Chang S. Bae <[email protected]> wrote:
>
> On 7/30/2026 2:26 PM, Andrei Vagin wrote:
> > On Tue, Jul 21, 2026 at 5:35 PM Andrei Vagin <[email protected]> wrote:
> >>   On Thu, Jul 9, 2026 at 2:15 PM Chang S. Bae <[email protected]> wrote:
> >>> On 7/7/2026 1:27 PM, Andrei Vagin wrote:
> >>>>
> >>>> Dynamic XSTATE components (like Intel AMX) require a process to
> >>>> explicitly request permission via arch_prctl(ARCH_REQ_XCOMP_PERM, ...).
> >>>> During the checkpoint, CRIU detects which dynamic features have been
> >>>> enabled for each thread and saves this configuration as part of the
> >>>> process image. During the restore, CRIU invokes arch_prctl() on threads
> >>>> to request the identical dynamic XSTATE permissions. If the target
> >>>> machine doesn't support a specific dynamic state, the restore will fail.
> >>>
> >>> The permission request itself does not expand a task's fpstate -- it
> >>> does not reallocate a larger XSAVE buffer or update its size/xfeatures
> >>> attributes.
> >>>
> >>> Assuming the target task has never touched the dynamic state, if
> >>> fx_sw->xstate_size > fpstate->user_size is permitted, while
> >>> fx_sw->xfeatures is still used directly as the XRSTOR RFBM, I think it
> >>> may be possible to trigger an ugly #NM in the kernel along the way when
> >>> CONFIG_X86_DEBUG_FPU=n. If CONFIG_X86_DEBUG_FPU=y, xfd_validate_state()
> >>> could guard this by clearing the bit as part of its consistency check.
> >>
> >> We never pass fx_sw->xfeatures directly to XRSTOR as the RFBM. In
> >> __restore_fpregs_from_user(), the restore mask is explicitly restricted:
> >>          xrestore_mask &= fpu->fpstate->user_xfeatures;
>
>
> You're right. I misread that path last time. Sigh...
>
> So, to summarize the implication with this patch:
>
> When migrating a user thread with a larger XSTATE layout, unless
> userspace prepares the destination (e.g., first touching the dynamic
> states to allocate the necessary backing storage), the side effect would
> be missing user data. There will be no notion of crash.

I think you are right. I missed that. Thanks for pointing it out.

To solve this, we can  enable the required dynamic features before
restoring the state. The nice thing about dynamic features is that
fx_sw->xfeatures includes them only if the task ever used them on the
source machine. Essentially, this means all requested   features must be
supported and permitted on the current machine in order for the restore
to succeed.

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;
}

Alternatively, we could omit the xstate_get_host_group_perm() masking
and simply require all proposed dynamic features to be enabled
successfully.

>
> Also, relaxing the size check nonetheless still means the signal frame
> has sufficient space to hold the states fitting into the destination
> task storage, correct?

We are restoring only the state supported by the current tasks, so
I don't think we have this problem. Do I miss something?

Thanks,
Andrei