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

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 7/30/2026 2:26 PM, Andrei Vagin wrote:
> On Tue, Jul 21, 2026 at 5:35 PM Andrei Vagin <avagin@gmail.com> wrote:
>>   On Thu, Jul 9, 2026 at 2:15 PM Chang S. Bae <chang.seok.bae@intel.com> 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.

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?

> Friendly ping on this patch.
Sorry for my delayed response.

Thanks,
Chang