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

[Chang S. Bae]

On 7/7/2026 1:27 PM, Andrei Vagin wrote:
> With this changes, the kernel will correctly reject signals frames with
> MPX states on APX machines and vise versa. If a signal frame contains an
> MPX state, it will be rejected on an APX machine because XCR0 will lack
> the MPX bits, causing XRSTOR to trigger a #GP. The exact same thing
> happens if a signal frame containing an APX state is brought to an older
> machine. XRSTOR explicitly triggers a #GP exception if a bit in XCR0 is
> 0 but the corresponding bit in the xstate_bv field of the XSAVE header
> is 1. This hardware enforcement occurs regardless of whether the target
> bit is present in the requested-feature bitmap.

Okay, in this regard, the interaction with XRSTOR in ring0 is ultimately 
what enforces the consistency check. Rather than trying to interpret the 
frame, let the kernel XRSTOR validate whether the image is migratable to 
the target or not. Perhaps, that's your perspective here all.

> 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.

If the restore path manages the destination fpstate before XRSTOR 
somehow, then this dynamic satate example isn't the case of migrating 
from larger to smaller frames. But I guess what you wanted here was 
stretching the "try-and-see" migration model to cover learger-to-smaller 
xstate-size transitions as well.

But again, from the kernel perspective, I feel this relaxation needs 
very careful review and auditing.

Thanks,
Chang