[PATCH 0/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[PATCH 0/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[Andrei Vagin]

When a process is checkpointed on one machine and restored on another
(e.g., via CRIU during container/process migration), any signal frame on
its stack carries the xstate layout of the source CPU.

Commit fd14edd82077 ("x86/fpu: Pre-fault only required size of xstate
buffer") enabled restoring signal frames created on CPUs with a smaller
xstate_size than the destination host's default. However,
check_xstate_in_sigframe() still enforces that a signal frame's
xstate_size must not exceed the current task's fpstate->user_size.

This restriction prevents migrating a process from a CPU with more
enabled xstate features to a CPU with fewer features, even when the
process has not actively used any of the unsupported features. Because
the actual set of active features is recorded in the XSAVE header
(XSTATE_BV) and validated during restoration, a larger xstate_size is
safe to restore as long as all active features are present in the
intersection of frame and task features and the buffer is large enough
for them.

Cc: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@kernel.org>

Andrei Vagin (2):
  x86/fpu: Allow restoring signal frames with larger xstate_size
  selftests/x86: Check restoring FPU state with larger xstate_size

 Documentation/arch/x86/xstate.rst                  |  10 +-
 arch/x86/kernel/fpu/signal.c                       |  31 +++++-
 .../selftests/x86/sigframe_fpu_portability.c       | 118 +++++++++++++++++++--
 3 files changed, 143 insertions(+), 16 deletions(-)

-- 
2.55.0.1082.g2b9226bbc0-goog

[PATCH 1/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[Andrei Vagin]

check_xstate_in_sigframe() currently enforces that fx_sw->xstate_size in
the signal frame must not exceed the current task's fpstate->user_size.
This prevents checkpoint/restore tools (such as CRIU) from migrating a
process that was saved on a CPU with a larger set of enabled xstate
features to a CPU with fewer features, even if the process did not
actively use any of the unsupported features.

Commit fd14edd82077 ("x86/fpu: Pre-fault only required size of xstate
buffer") introduced validation in check_xstate_in_sigframe() to
calculate the required buffer size from the intersection of
fx_sw->xfeatures and fpstate->user_xfeatures, and to shrink
fx_sw->xstate_size to that required size.

Remove the fx_sw->xstate_size > fpstate->user_size check so that signal
frames with a larger xstate_size can be restored when all active
features are supported. Because fx_sw->xstate_size is no longer bounded
by fpstate->user_size before reading the trailing FP_XSTATE_MAGIC2
marker, check for unsigned overflow when comparing fx_sw->xstate_size
against fx_sw->extended_size and use get_user() instead of __get_user()
when reading FP_XSTATE_MAGIC2.

When allowing a larger xstate_size, the kernel must still reject the
signal frame (resulting in SIGSEGV) if the XSAVE header (xstate_bv)
marks any unsupported feature as active. On the direct restore path,
XRSTOR raises #GP if any bit in xstate_bv is 1 while the corresponding
bit in XCR0 is 0, but this does not cover dynamically enabled features
(such as AMX XFEATURE_XTILE_DATA) that are enabled in XCR0 while
disabled for the task via MSR_IA32_XFD and fpstate->user_xfeatures.
Because __restore_fpregs_from_user() masks xrestore_mask (EDX:EAX) with
fpstate->user_xfeatures before executing XRSTOR (as kernel-mode XRSTOR
must not trigger an XFD #NM trap), XRSTOR would ignore XFD-disabled
components and silently drop their active state.

Therefore, explicitly validate in check_xstate_in_sigframe() that
xbuf->header.xfeatures (xstate_bv) only contains features present in the
intersection of fx_sw->xfeatures and fpstate->user_xfeatures. A
concurrent user-space modification of xbuf->header.xfeatures between
this check and XRSTOR cannot compromise the kernel: the restore mask
(EDX:EAX) is derived from the kernel copy of fx_sw and masked with
fpstate->user_xfeatures, so XRSTOR will either fault with #GP (if a bit
outside XCR0 is set) or ignore any bit not enabled in the restore mask
without touching its memory area or raising a kernel-mode #NM.

Update Documentation/arch/x86/xstate.rst to reflect that signal frames
with a larger xstate_size can be restored if all active features are
supported.

Signed-off-by: Andrei Vagin <avagin@google.com>
---
 Documentation/arch/x86/xstate.rst | 10 +++++++---
 arch/x86/kernel/fpu/signal.c      | 31 ++++++++++++++++++++++++++-----
 2 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/Documentation/arch/x86/xstate.rst b/Documentation/arch/x86/xstate.rst
index e2944f744255..f34bd06706d9 100644
--- a/Documentation/arch/x86/xstate.rst
+++ b/Documentation/arch/x86/xstate.rst
@@ -179,8 +179,9 @@ Signal Frame Layout and Portability
 The signal frame is designed to be self-describing and portable. This is
 especially important for checkpoint/restore tools like CRIU, which may restore
 a process on a different host than where it was checkpointed. A signal frame
-created on a machine with fewer CPU features can be successfully restored on a
-machine with more CPU features, but not vice-versa.
+can be successfully restored across machines with different sets of enabled
+CPU features (whether the frame's ``xstate_size`` is smaller or larger than the
+destination host's default), provided all active features are supported.
 
 Signal Frame Software Reserved Bytes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -222,7 +223,10 @@ Portability Constraints
 
 Signal frame portability is constrained by the architectural XSAVE layout.
 Restoration is supported only if the destination host supports all features
-present in the frame and uses matching component offsets and sizes for them.
+active in the XSAVE header (``XSTATE_BV``) and uses matching component offsets
+and sizes for them. (The frame's ``xstate_size`` and ``_fpx_sw_bytes.xfeatures``
+may exceed the destination host's default if the source host had additional
+features enabled that were not actively used by the task.)
 While layout compatibility is generally maintained across CPUs from the same
 vendor, differences can occur across vendors or if the XSAVE space of a
 deprecated feature (e.g. MPX) is repurposed for a newer feature (e.g. APX).
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 1f721ac84283..ce8939a9ce8f 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -36,11 +36,18 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *buf_fx,
 	if (__copy_from_user(fx_sw, &buf_fx->sw_reserved[0], sizeof(*fx_sw)))
 		return false;
 
-	/* Check for the first magic field and other error scenarios. */
+	/*
+	 * Check for the first magic field and other error scenarios.
+	 *
+	 * fx_sw->xstate_size can exceed fpstate->user_size if the frame was
+	 * saved on a CPU with a larger set of enabled xstate features.
+	 * Reject the buffer below if the XSAVE header contains any active
+	 * features that are not in both fx_sw->xfeatures and user_xfeatures.
+	 */
 	if (fx_sw->magic1 != FP_XSTATE_MAGIC1 ||
 	    fx_sw->xstate_size < min_xstate_size ||
-	    fx_sw->xstate_size > fpstate->user_size ||
-	    fx_sw->extended_size < fx_sw->xstate_size + FP_XSTATE_MAGIC2_SIZE)
+	    fx_sw->xstate_size > fx_sw->extended_size ||
+	    fx_sw->extended_size - fx_sw->xstate_size < FP_XSTATE_MAGIC2_SIZE)
 		goto err_setfx;
 
 	/*
@@ -49,19 +56,33 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *buf_fx,
 	 * fpstate layout with out copying the extended state information
 	 * in the memory layout.
 	 */
-	if (__get_user(magic2, (__u32 __user *)(buf + fx_sw->xstate_size)))
+	if (get_user(magic2, (__u32 __user *)(buf + fx_sw->xstate_size)))
 		return false;
 	if (unlikely(magic2 != FP_XSTATE_MAGIC2))
 		goto err_setfx;
 
 	if (fx_sw->xstate_size != fpstate->user_size ||
 	    fx_sw->xfeatures != fpstate->user_xfeatures) {
+		struct xregs_state __user *xbuf = buf;
+		u64 xstate_bv, xfeatures;
 		unsigned int xsize;
-		u64 xfeatures;
+
+		if (__get_user(xstate_bv, &xbuf->header.xfeatures))
+			return false;
 
 		/* Calculate size of enabled features only. */
 		xfeatures = fx_sw->xfeatures & fpstate->user_xfeatures;
 
+		/*
+		 * Reject XFD-disabled features present in XCR0 that XRSTOR
+		 * would otherwise ignore when masked out of EDX:EAX, as well
+		 * as any other active features not in xfeatures. Concurrent
+		 * user-space changes after this check cannot affect the kernel
+		 * because XRSTOR is masked with xfeatures.
+		 */
+		if (xstate_bv & ~xfeatures)
+			return false;
+
 		xsize = xstate_calculate_size(xfeatures, false);
 		if (fx_sw->xstate_size < xsize)
 			return false;
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

[PATCH 2/2] selftests/x86: Check restoring FPU state with larger xstate_size

[Andrei Vagin]

Extend sigframe_fpu_portability.c with two test cases for signal frames
whose xstate_size exceeds the current task's fpstate->user_size:

- test_valid_larger_xstate_size(): Verifies that the kernel restores FPU
  state from a signal frame with a larger xstate_size and an unsupported
  feature bit in _fpx_sw_bytes.xfeatures when the XSAVE header
  (XSTATE_BV) only contains supported features. This emulates migrating
  a process from a newer CPU to an older CPU when the process has not
  used any unsupported features.

- test_invalid_larger_xstate_size(): Verifies that the kernel rejects
  (via SIGSEGV) a signal frame with a larger xstate_size when the XSAVE
  header (XSTATE_BV) marks an unsupported feature as active.

Signed-off-by: Andrei Vagin <avagin@google.com>
---
 .../selftests/x86/sigframe_fpu_portability.c  | 118 ++++++++++++++++--
 1 file changed, 110 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/x86/sigframe_fpu_portability.c b/tools/testing/selftests/x86/sigframe_fpu_portability.c
index 8377de052032..afa9e6eab9b9 100644
--- a/tools/testing/selftests/x86/sigframe_fpu_portability.c
+++ b/tools/testing/selftests/x86/sigframe_fpu_portability.c
@@ -30,6 +30,14 @@
  * - test_invalid_shrunk_xstate_size:
  *   Verifies that the kernel rejects a frame if xstate_size is too small for
  *   the features enabled in xfeatures.
+ *
+ * - test_valid_larger_xstate_size:
+ *   Verifies that the kernel restores state from a frame with xstate_size
+ *   larger than the current task's size, if no unsupported features are active.
+ *
+ * - test_invalid_larger_xstate_size:
+ *   Verifies that the kernel rejects a frame with a larger xstate_size if it
+ *   contains unsupported features in the xsave header.
  */
 
 #define SIGFRAME_XSTATE_HDR_OFFSET	512
@@ -160,12 +168,13 @@ static void handle_invalid_shrunk_xstate_size(int sig, siginfo_t *si, void *ucp)
 	__handle_shrunk_xstate_size(sig, si, ucp, false);
 }
 
-static void test_valid_shrunk_xstate_size(void)
+static void run_valid_sigframe_test(void (*handler)(int, siginfo_t *, void *),
+				    const char *desc)
 {
 	uint64_t v[4];
 
 	sig_err_buf[0] = 0;
-	sethandler(SIGUSR1, handle_valid_shrunk_xstate_size, 0);
+	sethandler(SIGUSR1, handler, 0);
 
 	v[0] = 0x1111111111111111ULL;
 	v[1] = 0x2222222222222222ULL;
@@ -176,7 +185,7 @@ static void test_valid_shrunk_xstate_size(void)
 	if (sig_err_buf[0])
 		ksft_test_result_fail("%s\n", sig_err_buf);
 	else if (v[2] == TEST_YMMH_VAL && v[3] == (TEST_YMMH_VAL + 1))
-		ksft_test_result_pass("YMM state restored correctly from shrunk frame\n");
+		ksft_test_result_pass("%s\n", desc);
 	else
 		ksft_test_result_fail(
 				"Got upper bits: 0x%lx 0x%lx (expected %lx %lx)\n",
@@ -192,12 +201,13 @@ static void handle_segv(int sig, siginfo_t *si, void *ucp)
 	siglongjmp(segv_jmpbuf, 1);
 }
 
-static void test_invalid_shrunk_xstate_size(void)
+static void run_invalid_sigframe_test(void (*handler)(int, siginfo_t *, void *),
+				      const char *desc)
 {
 	uint64_t v[4];
 
 	sig_err_buf[0] = 0;
-	sethandler(SIGUSR1, handle_invalid_shrunk_xstate_size, 0);
+	sethandler(SIGUSR1, handler, 0);
 	sethandler(SIGSEGV, handle_segv, 0);
 
 	if (sigsetjmp(segv_jmpbuf, 1) == 0) {
@@ -206,7 +216,7 @@ static void test_invalid_shrunk_xstate_size(void)
 		v[2] = 0x3333333333333333ULL;
 		v[3] = 0x4444444444444444ULL;
 		raise_with_ymm0(SIGUSR1, v);
-		sig_print("Inconsistent size was NOT rejected\n");
+		sig_print("Invalid frame was NOT rejected\n");
 	}
 
 	clearhandler(SIGUSR1);
@@ -215,13 +225,103 @@ static void test_invalid_shrunk_xstate_size(void)
 	if (sig_err_buf[0])
 		ksft_test_result_fail("%s\n", sig_err_buf);
 	else
-		ksft_test_result_pass("Inconsistent size correctly rejected\n");
+		ksft_test_result_pass("%s\n", desc);
+}
+
+static void test_valid_shrunk_xstate_size(void)
+{
+	run_valid_sigframe_test(handle_valid_shrunk_xstate_size,
+				"YMM state restored correctly from shrunk frame");
+}
+
+static void test_invalid_shrunk_xstate_size(void)
+{
+	run_invalid_sigframe_test(handle_invalid_shrunk_xstate_size,
+				  "Inconsistent shrunk xstate_size correctly rejected");
+}
+
+static char fpu_buffer[8192] __attribute__((aligned(64)));
+#define UNSUPPORTED_XFEATURE (1ULL << 62)
+
+static void __handle_larger_xstate_size(int sig, siginfo_t *si, void *ucp, bool valid_xfeatures)
+{
+	uint64_t *ymmh_p, xfeatures;
+	struct xsave_buffer *xbuf;
+	struct _fpx_sw_bytes *sw;
+	ucontext_t *uc = ucp;
+	size_t copy_size;
+	void *fp;
+
+	fp = uc->uc_mcontext.fpregs;
+	if (!fp) {
+		sig_print("fpregs is NULL\n");
+		return;
+	}
+
+	sw = get_fpx_sw_bytes(fp);
+	if (sw->magic1 != FP_XSTATE_MAGIC1) {
+		sig_print("magic1 is not valid\n");
+		return;
+	}
+
+	copy_size = sw->xstate_size;
+	if (copy_size + 64 + FP_XSTATE_MAGIC2_SIZE > sizeof(fpu_buffer)) {
+		sig_print("fpu_buffer is too small\n");
+		return;
+	}
+
+	memset(fpu_buffer, 0, sizeof(fpu_buffer));
+	memcpy(fpu_buffer, fp, copy_size);
+
+	xbuf = (struct xsave_buffer *)fpu_buffer;
+	sw = get_fpx_sw_bytes(fpu_buffer);
+
+	sw->xstate_size += 64;
+	sw->extended_size += 64;
+	xfeatures = get_fpx_sw_bytes_features(fpu_buffer);
+	set_fpx_sw_bytes_features(fpu_buffer, xfeatures | UNSUPPORTED_XFEATURE);
+
+	*(uint32_t *)(fpu_buffer + sw->xstate_size) = FP_XSTATE_MAGIC2;
+
+	if (!valid_xfeatures) {
+		xfeatures = get_xstatebv(xbuf);
+		set_xstatebv(xbuf, xfeatures | UNSUPPORTED_XFEATURE);
+	}
+
+	ymmh_p = (uint64_t *)(fpu_buffer + ymm_offset);
+	ymmh_p[0] = TEST_YMMH_VAL;
+	ymmh_p[1] = TEST_YMMH_VAL + 1;
+
+	/* Update fpregs to point to the new buffer */
+	uc->uc_mcontext.fpregs = (fpregset_t)fpu_buffer;
+}
+
+static void handle_valid_larger_xstate_size(int sig, siginfo_t *si, void *ucp)
+{
+	__handle_larger_xstate_size(sig, si, ucp, true);
+}
+
+static void handle_invalid_larger_xstate_size(int sig, siginfo_t *si, void *ucp)
+{
+	__handle_larger_xstate_size(sig, si, ucp, false);
+}
+
+static void test_valid_larger_xstate_size(void)
+{
+	run_valid_sigframe_test(handle_valid_larger_xstate_size,
+				"YMM state restored correctly from larger frame");
+}
+
+static void test_invalid_larger_xstate_size(void)
+{
+	run_invalid_sigframe_test(handle_invalid_larger_xstate_size,
+				  "Unsupported feature in larger frame correctly rejected");
 }
 
 int main(void)
 {
 	ksft_print_header();
-	ksft_set_plan(2);
+	ksft_set_plan(4);
 
 	self_pid = getpid();
 
@@ -229,6 +329,8 @@ int main(void)
 
 	test_valid_shrunk_xstate_size();
 	test_invalid_shrunk_xstate_size();
+	test_valid_larger_xstate_size();
+	test_invalid_larger_xstate_size();
 
 	ksft_finished();
 	return 0;
-- 
2.56.0.rc1.315.gc6ed9934b7-goog

Re: [PATCH 0/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[Borislav Petkov]

On Tue, Sep 29, 2026 at 11:26:19PM +0000, Andrei Vagin wrote:
> When a process is checkpointed on one machine and restored on another
> (e.g., via CRIU during container/process migration), any signal frame on
> its stack carries the xstate layout of the source CPU.
> 
> Commit fd14edd82077 ("x86/fpu: Pre-fault only required size of xstate
> buffer") enabled restoring signal frames created on CPUs with a smaller
> xstate_size than the destination host's default. However,
> check_xstate_in_sigframe() still enforces that a signal frame's
> xstate_size must not exceed the current task's fpstate->user_size.

Hmm, what happened? Change of heart after the fact?

So I guess I am zapping fd14edd82077 from tip:x86/fpu now and then we test
some more before we try this again?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 0/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[Andrei Vagin]

On Tue, Sep 29, 2026 at 4:57 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Sep 29, 2026 at 11:26:19PM +0000, Andrei Vagin wrote:
> > When a process is checkpointed on one machine and restored on another
> > (e.g., via CRIU during container/process migration), any signal frame on
> > its stack carries the xstate layout of the source CPU.
> >
> > Commit fd14edd82077 ("x86/fpu: Pre-fault only required size of xstate
> > buffer") enabled restoring signal frames created on CPUs with a smaller
> > xstate_size than the destination host's default. However,
> > check_xstate_in_sigframe() still enforces that a signal frame's
> > xstate_size must not exceed the current task's fpstate->user_size.
>
> Hmm, what happened? Change of heart after the fact?
>
> So I guess I am zapping fd14edd82077 from tip:x86/fpu now and then we test
> some more before we try this again?

I think it is a misunderstanding. This series is actually the next step.
The first series enabled migrating workloads from older CPUs to newer
ones. This series enables migrating workloads from newer CPUs to older
ones.

Thanks,
Andrei

Re: [PATCH 0/2] x86/fpu: Allow restoring signal frames with larger xstate_size

[Borislav Petkov]

On Tue, Sep 29, 2026 at 05:02:50PM -0700, Andrei Vagin wrote:
> I think it is a misunderstanding. This series is actually the next step.
> The first series enabled migrating workloads from older CPUs to newer
> ones. This series enables migrating workloads from newer CPUs to older
> ones.

Aha. Any particular reason you're sending this separately, after the previous
set?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette