* [PATCH v1 1/1] x86/fred: Set SS to __KERNEL_DS when enabling FRED
@ 2024-08-16 10:43 Xin Li (Intel)
2024-08-25 14:29 ` [tip: x86/fred] " tip-bot2 for Xin Li (Intel)
0 siblings, 1 reply; 2+ messages in thread
From: Xin Li (Intel) @ 2024-08-16 10:43 UTC (permalink / raw)
To: linux-kernel; +Cc: tglx, mingo, bp, dave.hansen, hpa, x86
SS is initialized to NULL during boot time and not *explicitly* set to
__KERNEL_DS.
With FRED enabled, if a kernel event is delivered before a CPU goes to
user level for the first time, its SS is NULL thus NULL is pushed into
the SS field of the FRED stack frame. But before ERETS is executed,
the CPU may context switch to another task and go to user level. Then
when the CPU comes back to kernel mode, SS is changed to __KERNEL_DS.
Later when ERETS is executed to return from the kernel event handler,
a #GP fault is generated because SS doesn't match the SS saved in the
FRED stack frame.
Initialize SS to __KERNEL_DS when enabling FRED to avoid such #GPs.
Note, IRET doesn't check if SS matches the SS saved in its stack frame,
thus IDT doesn't have this problem. For IDT it doesn't matter whether
SS is set to __KERNEL_DS or not, because it's set to NULL upon interrupt
or exception delivery and __KERNEL_DS upon SYSCALL. Thus it's pointless
to initialize SS for IDT.
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
---
arch/x86/kernel/fred.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index 99a134fcd5bf..266c69e332a4 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -26,6 +26,20 @@ void cpu_init_fred_exceptions(void)
/* When FRED is enabled by default, remove this log message */
pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
+ /*
+ * If a kernel event is delivered before a CPU goes to user level for
+ * the first time, its SS is NULL thus NULL is pushed into the SS field
+ * of the FRED stack frame. But before ERETS is executed, the CPU may
+ * context switch to another task and go to user level. Then when the
+ * CPU comes back to kernel mode, SS is changed to __KERNEL_DS. Later
+ * when ERETS is executed to return from the kernel event handler, a #GP
+ * fault is generated because SS doesn't match the SS saved in the FRED
+ * stack frame.
+ *
+ * Initialize SS to __KERNEL_DS when enabling FRED to avoid such #GPs.
+ */
+ loadsegment(ss, __KERNEL_DS);
+
wrmsrl(MSR_IA32_FRED_CONFIG,
/* Reserve for CALL emulation */
FRED_CONFIG_REDZONE |
base-commit: a97756cbec448032f84b5bbfe4e101478d1e01e0
--
2.46.0
^ permalink raw reply [flat|nested] 2+ messages in thread
* [tip: x86/fred] x86/fred: Set SS to __KERNEL_DS when enabling FRED
2024-08-16 10:43 [PATCH v1 1/1] x86/fred: Set SS to __KERNEL_DS when enabling FRED Xin Li (Intel)
@ 2024-08-25 14:29 ` tip-bot2 for Xin Li (Intel)
0 siblings, 0 replies; 2+ messages in thread
From: tip-bot2 for Xin Li (Intel) @ 2024-08-25 14:29 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Xin Li (Intel), Thomas Gleixner, x86, linux-kernel
The following commit has been merged into the x86/fred branch of tip:
Commit-ID: 723edbd2ca5fb4c78ac4a5644511c63895fd1c57
Gitweb: https://git.kernel.org/tip/723edbd2ca5fb4c78ac4a5644511c63895fd1c57
Author: Xin Li (Intel) <xin@zytor.com>
AuthorDate: Fri, 16 Aug 2024 03:43:16 -07:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Sun, 25 Aug 2024 16:24:52 +02:00
x86/fred: Set SS to __KERNEL_DS when enabling FRED
SS is initialized to NULL during boot time and not explicitly set to
__KERNEL_DS.
With FRED enabled, if a kernel event is delivered before a CPU goes to
user level for the first time, its SS is NULL thus NULL is pushed into
the SS field of the FRED stack frame. But before ERETS is executed,
the CPU may context switch to another task and go to user level. Then
when the CPU comes back to kernel mode, SS is changed to __KERNEL_DS.
Later when ERETS is executed to return from the kernel event handler,
a #GP fault is generated because SS doesn't match the SS saved in the
FRED stack frame.
Initialize SS to __KERNEL_DS when enabling FRED to prevent that.
Note, IRET doesn't check if SS matches the SS saved in its stack frame,
thus IDT doesn't have this problem. For IDT it doesn't matter whether
SS is set to __KERNEL_DS or not, because it's set to NULL upon interrupt
or exception delivery and __KERNEL_DS upon SYSCALL. Thus it's pointless
to initialize SS for IDT.
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20240816104316.2276968-1-xin@zytor.com
---
arch/x86/kernel/fred.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c
index 99a134f..266c69e 100644
--- a/arch/x86/kernel/fred.c
+++ b/arch/x86/kernel/fred.c
@@ -26,6 +26,20 @@ void cpu_init_fred_exceptions(void)
/* When FRED is enabled by default, remove this log message */
pr_info("Initialize FRED on CPU%d\n", smp_processor_id());
+ /*
+ * If a kernel event is delivered before a CPU goes to user level for
+ * the first time, its SS is NULL thus NULL is pushed into the SS field
+ * of the FRED stack frame. But before ERETS is executed, the CPU may
+ * context switch to another task and go to user level. Then when the
+ * CPU comes back to kernel mode, SS is changed to __KERNEL_DS. Later
+ * when ERETS is executed to return from the kernel event handler, a #GP
+ * fault is generated because SS doesn't match the SS saved in the FRED
+ * stack frame.
+ *
+ * Initialize SS to __KERNEL_DS when enabling FRED to avoid such #GPs.
+ */
+ loadsegment(ss, __KERNEL_DS);
+
wrmsrl(MSR_IA32_FRED_CONFIG,
/* Reserve for CALL emulation */
FRED_CONFIG_REDZONE |
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-08-25 14:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-16 10:43 [PATCH v1 1/1] x86/fred: Set SS to __KERNEL_DS when enabling FRED Xin Li (Intel)
2024-08-25 14:29 ` [tip: x86/fred] " tip-bot2 for Xin Li (Intel)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®