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

"Chang S. Bae" <[email protected]> Fri, 10 Jul 2026 15:24:38 -0700
Newsgroups dev.linux.lists.criu,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 7/9/2026 2:14 PM, Chang S. Bae wrote:
> 
> 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.


Bah, I should have doubted myself how the debug option could alter the 
behavior. No, it only emits a warning out if it detects an inconsistency 
between the RFBM and XFD state. So a screwed sigframe could still 
trigger an in-kernel #NM during XRSTOR regardless of that config. The 
relevant text from SDM Vol. 1 Section 13.14 says:

   If XRSTOR or XRSTORS is loading state component i and bit i of the
   XSTATE_BV field of the XSAVE header is 0, the instruction does not
   generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it initializes
   the state component normally. (If bit i of the XSTATE_BV field of the
   XSAVE header is 1, the instruction does generate #NM.)

Thanks,
Chang