linux-kernel - [tip: x86/urgent] x86/fred: Fix system hang during S4 resume with FRED enabled

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <174342460045.14745.9243605913254959856.tip-bot2@tip-bot2>
Date: Mon, 31 Mar 2025 12:36:40 -0000
From: "tip-bot2 for Xin Li (Intel)" <tip-bot2@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: Xi Pardee <xi.pardee@...el.com>, Todd Brandt <todd.e.brandt@...el.com>,
 "H. Peter Anvin (Intel)" <hpa@...or.com>, "Xin Li (Intel)" <xin@...or.com>,
 Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
 Brian Gerst <brgerst@...il.com>, Juergen Gross <jgross@...e.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: [tip: x86/urgent] x86/fred: Fix system hang during S4 resume with
 FRED enabled

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

Commit-ID:     b578bfe07ae943937a2945a9f6ac4b497f4d4e09
Gitweb:        https://git.kernel.org/tip/b578bfe07ae943937a2945a9f6ac4b497f4d4e09
Author:        Xin Li (Intel) <xin@...or.com>
AuthorDate:    Tue, 25 Mar 2025 23:25:40 -07:00
Committer:     Ingo Molnar <mingo@...nel.org>
CommitterDate: Mon, 31 Mar 2025 14:19:35 +02:00

x86/fred: Fix system hang during S4 resume with FRED enabled

During an S4 resume, the system first performs a cold power-on.  The
kernel image is initially loaded to a random linear address, and the
FRED MSRs are initialized.  Subsequently, the S4 image is loaded,
and the kernel image is relocated to its original address from before
the S4 suspend.  Due to changes in the kernel text and data mappings,
the FRED MSRs must be reinitialized with new values.

[ mingo: Rephrased & clarified the comments. ]

Reported-by: Xi Pardee <xi.pardee@...el.com>
Reported-by: Todd Brandt <todd.e.brandt@...el.com>
Suggested-by: H. Peter Anvin (Intel) <hpa@...or.com>
Signed-off-by: Xin Li (Intel) <xin@...or.com>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
Tested-by: Todd Brandt <todd.e.brandt@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Brian Gerst <brgerst@...il.com>
Cc: Juergen Gross <jgross@...e.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Link: https://lore.kernel.org/r/20250326062540.820556-1-xin@zytor.com
---
 arch/x86/power/cpu.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 63230ff..70c8906 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -27,6 +27,7 @@
 #include <asm/mmu_context.h>
 #include <asm/cpu_device_id.h>
 #include <asm/microcode.h>
+#include <asm/fred.h>

 #ifdef CONFIG_X86_32
 __visible unsigned long saved_context_ebx;
@@ -231,6 +232,25 @@ static void notrace __restore_processor_state(struct saved_context *ctxt)
 	 */
 #ifdef CONFIG_X86_64
 	wrmsrl(MSR_GS_BASE, ctxt->kernelmode_gs_base);
+
+	/*
+	 * Restore FRED settings.
+	 *
+	 * FRED settings can be completely derived from
+	 * current kernel text and data data mappings, thus
+	 * nothing needs to be saved and restored.
+	 *
+	 * As such, simply re-initialize FRED to restore the FRED
+	 * settings. Note that any changes to text and data mappings
+	 * after S4 resume will generate different FRED configuration
+	 * values.
+	 *
+	 * Also, FRED RSPs setup needs to access per-CPU data structures.
+	 */
+	if (ctxt->cr4 & X86_CR4_FRED) {
+		cpu_init_fred_exceptions();
+		cpu_init_fred_rsps();
+	}
 #else
 	loadsegment(fs, __KERNEL_PERCPU);
 #endif