The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Andrei Vagin <avagin@google.com>
To: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	 "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: linux-kernel@vger.kernel.org, criu@lists.linux.dev,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,  Andrei Vagin <avagin@google.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: [PATCH 04/10] x86/fpu: Document reasoning of FX-only fallback
Date: Mon, 15 Jun 2026 19:37:10 +0000	[thread overview]
Message-ID: <20260615193716.1843340-5-avagin@google.com> (raw)
In-Reply-To: <20260615193716.1843340-1-avagin@google.com>

Add a comment to check_xstate_in_sigframe() to explain reasoning behind
falling back to the FX-only state when signal frame metadata is
inconsistent.

The fallback is intended to preserve backward compatibility with legacy
user-space processes that are not aware of XSAVE states and might only
fill or copy just the legacy FP state.

This fallback is dangerous as it can trigger silent corruptions of
user-space state by resetting extended registers if the process was
using them but the frame metadata was malformed.

XSAVE was introduced 15 years ago, we may need to consider removing this
fallback entirely or introducing a sysctl to enable/disable it.

Signed-off-by: Andrei Vagin <avagin@google.com>
---
 arch/x86/kernel/fpu/signal.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 6a14b528ac7f..85021c5ea649 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -54,6 +54,14 @@ static inline bool check_xstate_in_sigframe(struct fxregs_state __user *buf_fx,
 	if (likely(magic2 == FP_XSTATE_MAGIC2))
 		return true;
 err_setfx:
+	/*
+	 * The fallback to FX-only state is used to preserve backward
+	 * compatibility with user-space processes that are not aware of xsave
+	 * states.
+	 *
+	 * In all other cases, returning false (to trigger SIGSEGV) is
+	 * preferred to avoid silent user-space state corruption.
+	 */
 	trace_x86_fpu_xstate_check_failed(x86_task_fpu(current));
 
 	/* Set the parameters for fx only state */
-- 
2.54.0.1189.g8c84645362-goog


  parent reply	other threads:[~2026-06-15 19:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-15 19:37 [PATCH v3 0/10] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-06-15 19:37 ` [PATCH 01/10] x86/fpu: Document " Andrei Vagin
2026-06-26 13:51   ` Alexander Mikhalitsyn
2026-06-30 19:23   ` Chang S. Bae
2026-06-15 19:37 ` [PATCH 02/10] x86/fpu: Clean up and rename variables in signal frame handling Andrei Vagin
2026-06-26 17:05   ` Alexander Mikhalitsyn
2026-06-15 19:37 ` [PATCH 03/10] x86/fpu: Split __fpu_restore_sig to extract compat path Andrei Vagin
2026-06-26 17:20   ` Alexander Mikhalitsyn
2026-06-15 19:37 ` Andrei Vagin [this message]
2026-06-26 14:22   ` [PATCH 04/10] x86/fpu: Document reasoning of FX-only fallback Alexander Mikhalitsyn
2026-06-30 19:23   ` Chang S. Bae
2026-06-15 19:37 ` [PATCH 05/10] x86/fpu: Fix potential underflow in xstate_calculate_size() Andrei Vagin
2026-06-26 14:32   ` Alexander Mikhalitsyn
2026-06-30 19:23   ` Chang S. Bae
2026-06-15 19:37 ` [PATCH 06/10] selftests/x86: Add a test for signal frame FPU portability Andrei Vagin
2026-06-26 14:39   ` Alexander Mikhalitsyn
2026-06-15 19:37 ` [PATCH 07/10] x86/fpu: Pre-fault only required size of xstate buffer Andrei Vagin
2026-06-26 17:28   ` Alexander Mikhalitsyn
2026-06-15 19:37 ` [PATCH 08/10] selftests/x86: Add a sigframe insufficient xstate_size test Andrei Vagin
2026-06-26 15:02   ` Alexander Mikhalitsyn
2026-06-15 19:37 ` [PATCH 09/10] x86/fpu: Allow restoring signal frames with larger xstate_size Andrei Vagin
2026-06-26 17:32   ` Alexander Mikhalitsyn
2026-06-30 19:23   ` Chang S. Bae
2026-07-01  0:48     ` Andrei Vagin
2026-06-15 19:37 ` [PATCH 10/10] selftests/x86: Check restoring FPU state " Andrei Vagin
2026-06-26 15:12   ` Alexander Mikhalitsyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260615193716.1843340-5-avagin@google.com \
    --to=avagin@google.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=criu@lists.linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox