linux-kernel - [tip: x86/urgent] x86/fred: Fix the FRED RSP0 MSR out of sync with its per-CPU cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <173693266685.31546.12884479664258205675.tip-bot2@tip-bot2>
Date: Wed, 15 Jan 2025 09:17:46 -0000
From: "tip-bot2 for Xin Li (Intel)" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: "Xin Li (Intel)" <xin@...or.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, stable@...r.kernel.org,
 x86@...nel.org, linux-kernel@...r.kernel.org
Subject: [tip: x86/urgent] x86/fred: Fix the FRED RSP0 MSR out of sync with
 its per-CPU cache

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     de31b3cd706347044e1a57d68c3a683d58e8cca4
Gitweb:        https://git.kernel.org/tip/de31b3cd706347044e1a57d68c3a683d58e8cca4
Author:        Xin Li (Intel) <xin@...or.com>
AuthorDate:    Fri, 10 Jan 2025 09:46:39 -08:00
Committer:     Dave Hansen <dave.hansen@...ux.intel.com>
CommitterDate: Tue, 14 Jan 2025 14:16:36 -08:00

x86/fred: Fix the FRED RSP0 MSR out of sync with its per-CPU cache

The FRED RSP0 MSR is only used for delivering events when running
userspace.  Linux leverages this property to reduce expensive MSR
writes and optimize context switches.  The kernel only writes the
MSR when about to run userspace *and* when the MSR has actually
changed since the last time userspace ran.

This optimization is implemented by maintaining a per-CPU cache of
FRED RSP0 and then checking that against the value for the top of
current task stack before running userspace.

However cpu_init_fred_exceptions() writes the MSR without updating
the per-CPU cache.  This means that the kernel might return to
userspace with MSR_IA32_FRED_RSP0==0 when it needed to point to the
top of current task stack.  This would induce a double fault (#DF),
which is bad.

A context switch after cpu_init_fred_exceptions() can paper over
the issue since it updates the cached value.  That evidently
happens most of the time explaining how this bug got through.

Fix the bug through resynchronizing the FRED RSP0 MSR with its
per-CPU cache in cpu_init_fred_exceptions().

Fixes: fe85ee391966 ("x86/entry: Set FRED RSP0 on return to userspace instead of context switch")
Signed-off-by: Xin Li (Intel) <xin@...or.com>
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Cc:stable@...r.kernel.org
Link: https://lore.kernel.org/all/20250110174639.1250829-1-xin%40zytor.com
---
 arch/x86/kernel/fred.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index 8d32c3f..5e2cd10 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -50,7 +50,13 @@ void cpu_init_fred_exceptions(void)
 	       FRED_CONFIG_ENTRYPOINT(asm_fred_entrypoint_user));

 	wrmsrl(MSR_IA32_FRED_STKLVLS, 0);
-	wrmsrl(MSR_IA32_FRED_RSP0, 0);
+
+	/*
+	 * Ater a CPU offline/online cycle, the FRED RSP0 MSR should be
+	 * resynchronized with its per-CPU cache.
+	 */
+	wrmsrl(MSR_IA32_FRED_RSP0, __this_cpu_read(fred_rsp0));
+
 	wrmsrl(MSR_IA32_FRED_RSP1, 0);
 	wrmsrl(MSR_IA32_FRED_RSP2, 0);
 	wrmsrl(MSR_IA32_FRED_RSP3, 0);