* Re: [patch 1/3] x86/fpu: Prevent FPU state corruption
2022-05-01 19:31 ` [patch 1/3] x86/fpu: Prevent FPU state corruption Thomas Gleixner
@ 2022-05-02 13:16 ` Borislav Petkov
2022-05-05 0:42 ` [tip: x86/urgent] " tip-bot2 for Thomas Gleixner
1 sibling, 0 replies; 3+ messages in thread
From: Borislav Petkov @ 2022-05-02 13:16 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, x86, Filipe Manana, stable
On Sun, May 01, 2022 at 09:31:43PM +0200, Thomas Gleixner wrote:
> The latter is checking whether some other context already uses FPU in the
> kernel, but if that's not the case then it allows FPU to be used
> unconditionally even if the calling context interupted a fpregs_lock()
Unknown word [interupted] in commit message.
Suggestions: ['interrupted', ...
> /*
> * Can we use the FPU in kernel mode with the
> * whole "kernel_fpu_begin/end()" sequence?
While at it, drop the "we": "Can the FPU be used in kernel mode... "
> - *
> - * It's always ok in process context (ie "not interrupt")
> - * but it is sometimes ok even from an irq.
> */
> bool irq_fpu_usable(void)
> {
> - return !in_interrupt() ||
> - interrupted_user_mode() ||
> - interrupted_kernel_fpu_idle();
> + if (WARN_ON_ONCE(in_nmi()))
> + return false;
> +
> + /* In kernel FPU usage already active? */
> + if (this_cpu_read(in_kernel_fpu))
> + return false;
> +
> + /*
> + * When not in NMI or hard interrupt context, FPU can be used:
"... can be used in:"
> + *
> + * - Task context is safe except from within fpregs_lock()'ed
> + * critical regions.
> + *
> + * - Soft interrupt processing context which cannot happen
> + * while in a fpregs_lock()'ed critical region.
But those are only nitpicks. With those fixed:
Reviewed-by: Borislav Petkov <bp@suse.de>
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 3+ messages in thread* [tip: x86/urgent] x86/fpu: Prevent FPU state corruption
2022-05-01 19:31 ` [patch 1/3] x86/fpu: Prevent FPU state corruption Thomas Gleixner
2022-05-02 13:16 ` Borislav Petkov
@ 2022-05-05 0:42 ` tip-bot2 for Thomas Gleixner
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot2 for Thomas Gleixner @ 2022-05-05 0:42 UTC (permalink / raw)
To: linux-tip-commits
Cc: Filipe Manana, Thomas Gleixner, Borislav Petkov, stable, x86,
linux-kernel
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 59f5ede3bc0f00eb856425f636dab0c10feb06d8
Gitweb: https://git.kernel.org/tip/59f5ede3bc0f00eb856425f636dab0c10feb06d8
Author: Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Sun, 01 May 2022 21:31:43 +02:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Thu, 05 May 2022 02:40:19 +02:00
x86/fpu: Prevent FPU state corruption
The FPU usage related to task FPU management is either protected by
disabling interrupts (switch_to, return to user) or via fpregs_lock() which
is a wrapper around local_bh_disable(). When kernel code wants to use the
FPU then it has to check whether it is possible by calling irq_fpu_usable().
But the condition in irq_fpu_usable() is wrong. It allows FPU to be used
when:
!in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()
The latter is checking whether some other context already uses FPU in the
kernel, but if that's not the case then it allows FPU to be used
unconditionally even if the calling context interrupted a fpregs_lock()
critical region. If that happens then the FPU state of the interrupted
context becomes corrupted.
Allow in kernel FPU usage only when no other context has in kernel FPU
usage and either the calling context is not hard interrupt context or the
hard interrupt did not interrupt a local bottomhalf disabled region.
It's hard to find a proper Fixes tag as the condition was broken in one way
or the other for a very long time and the eager/lazy FPU changes caused a
lot of churn. Picked something remotely connected from the history.
This survived undetected for quite some time as FPU usage in interrupt
context is rare, but the recent changes to the random code unearthed it at
least on a kernel which had FPU debugging enabled. There is probably a
higher rate of silent corruption as not all issues can be detected by the
FPU debugging code. This will be addressed in a subsequent change.
Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave")
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20220501193102.588689270@linutronix.de
---
arch/x86/kernel/fpu/core.c | 67 ++++++++++++++-----------------------
1 file changed, 26 insertions(+), 41 deletions(-)
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index c049561..e28ab0e 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -41,17 +41,7 @@ struct fpu_state_config fpu_user_cfg __ro_after_init;
*/
struct fpstate init_fpstate __ro_after_init;
-/*
- * Track whether the kernel is using the FPU state
- * currently.
- *
- * This flag is used:
- *
- * - by IRQ context code to potentially use the FPU
- * if it's unused.
- *
- * - to debug kernel_fpu_begin()/end() correctness
- */
+/* Track in-kernel FPU usage */
static DEFINE_PER_CPU(bool, in_kernel_fpu);
/*
@@ -59,42 +49,37 @@ static DEFINE_PER_CPU(bool, in_kernel_fpu);
*/
DEFINE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
-static bool kernel_fpu_disabled(void)
-{
- return this_cpu_read(in_kernel_fpu);
-}
-
-static bool interrupted_kernel_fpu_idle(void)
-{
- return !kernel_fpu_disabled();
-}
-
-/*
- * Were we in user mode (or vm86 mode) when we were
- * interrupted?
- *
- * Doing kernel_fpu_begin/end() is ok if we are running
- * in an interrupt context from user mode - we'll just
- * save the FPU state as required.
- */
-static bool interrupted_user_mode(void)
-{
- struct pt_regs *regs = get_irq_regs();
- return regs && user_mode(regs);
-}
-
/*
* Can we use the FPU in kernel mode with the
* whole "kernel_fpu_begin/end()" sequence?
- *
- * It's always ok in process context (ie "not interrupt")
- * but it is sometimes ok even from an irq.
*/
bool irq_fpu_usable(void)
{
- return !in_interrupt() ||
- interrupted_user_mode() ||
- interrupted_kernel_fpu_idle();
+ if (WARN_ON_ONCE(in_nmi()))
+ return false;
+
+ /* In kernel FPU usage already active? */
+ if (this_cpu_read(in_kernel_fpu))
+ return false;
+
+ /*
+ * When not in NMI or hard interrupt context, FPU can be used in:
+ *
+ * - Task context except from within fpregs_lock()'ed critical
+ * regions.
+ *
+ * - Soft interrupt processing context which cannot happen
+ * while in a fpregs_lock()'ed critical region.
+ */
+ if (!in_hardirq())
+ return true;
+
+ /*
+ * In hard interrupt context it's safe when soft interrupts
+ * are enabled, which means the interrupt did not hit in
+ * a fpregs_lock()'ed critical region.
+ */
+ return !softirq_count();
}
EXPORT_SYMBOL(irq_fpu_usable);
^ permalink raw reply related [flat|nested] 3+ messages in thread