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