All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: speck@linutronix.de
Subject: [patch V6 07/14] MDS basics 7
Date: Fri, 01 Mar 2019 22:47:45 +0100	[thread overview]
Message-ID: <20190301214847.807540001@linutronix.de> (raw)
In-Reply-To: 20190301214738.281554861@linutronix.de

Subject: [patch V6 07/14] x86/speculation/mds: Clear CPU buffers on exit to user
From: Thomas Gleixner <tglx@linutronix.de>

Add a static key which controls the invocation of the CPU buffer clear
mechanism on exit to user space and add the call into
prepare_exit_to_usermode() and do_nmi() right before actually returning.

Add documentation which kernel to user space transition this covers and
explain why some corner cases are not mitigated.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
V4 --> v5: Use an inline helper instead of open coding it.
	   Rework the documentation paragraph about exceptions.

V3 --> V4: Add #DS mitigation and document that the #MC corner case
       	   is really not interesting.

V3: Add NMI conditional on user regs and update documentation accordingly.
    Use the static branch scheme suggested by Peter. Fix typos ...
---
 Documentation/x86/mds.rst            |   52 +++++++++++++++++++++++++++++++++++
 arch/x86/entry/common.c              |    3 ++
 arch/x86/include/asm/nospec-branch.h |   13 ++++++++
 arch/x86/kernel/cpu/bugs.c           |    3 ++
 arch/x86/kernel/nmi.c                |    4 ++
 arch/x86/kernel/traps.c              |    7 ++++
 6 files changed, 82 insertions(+)

--- a/Documentation/x86/mds.rst
+++ b/Documentation/x86/mds.rst
@@ -97,3 +97,55 @@ According to current knowledge additiona
 itself are not required because the necessary gadgets to expose the leaked
 data cannot be controlled in a way which allows exploitation from malicious
 user space or VM guests.
+
+Mitigation points
+-----------------
+
+1. Return to user space
+^^^^^^^^^^^^^^^^^^^^^^^
+
+   When transitioning from kernel to user space the CPU buffers are flushed
+   on affected CPUs when the mitigation is not disabled on the kernel
+   command line. The migitation is enabled through the static key
+   mds_user_clear.
+
+   The mitigation is invoked in prepare_exit_to_usermode() which covers
+   most of the kernel to user space transitions. There are a few exceptions
+   which are not invoking prepare_exit_to_usermode() on return to user
+   space. These exceptions use the paranoid exit code.
+
+   - Non Maskable Interrupt (NMI):
+
+     Access to sensible data like keys, credentials in the NMI context is
+     mostly theoretical: The CPU can do prefetching or execute a
+     misspeculated code path and thereby fetching data which might end up
+     leaking through a buffer.
+
+     But for mounting other attacks the kernel stack address of the task is
+     already valuable information. So in full mitigation mode, the NMI is
+     mitigated on the return from do_nmi() to provide almost complete
+     coverage.
+
+   - Double fault (#DF):
+
+     A double fault is usually fatal, but the ESPFIX workaround, which can
+     be triggered from user space through modify_ldt(2) is a recoverable
+     double fault. #DF uses the paranoid exit path, so explicit mitigation
+     in the double fault handler is required.
+
+   - Machine Check Exception (#MC):
+
+     Another corner case is a #MC which hits between the CPU buffer clear
+     invocation and the actual return to user. As this still is in kernel
+     space it takes the paranoid exit path which does not clear the CPU
+     buffers. So the #MC handler repopulates the buffers to some
+     extent. Machine checks are not reliably controllable and the window is
+     extremly small so mitigation would just tick a checkbox that this
+     theoretical corner case is covered. To keep the amount of special
+     cases small, ignore #MC.
+
+   - Debug Exception (#DB):
+
+     This takes the paranoid exit path only when the INT1 breakpoint is in
+     kernel space. #DB on a user space address takes the regular exit path,
+     so no extra mitigation required.
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -31,6 +31,7 @@
 #include <asm/vdso.h>
 #include <linux/uaccess.h>
 #include <asm/cpufeature.h>
+#include <asm/nospec-branch.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/syscalls.h>
@@ -212,6 +213,8 @@ static void exit_to_usermode_loop(struct
 #endif
 
 	user_enter_irqoff();
+
+	mds_user_clear_cpu_buffers();
 }
 
 #define SYSCALL_EXIT_WORK_FLAGS				\
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -318,6 +318,8 @@ DECLARE_STATIC_KEY_FALSE(switch_to_cond_
 DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
 DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
+DECLARE_STATIC_KEY_FALSE(mds_user_clear);
+
 #include <asm/segment.h>
 
 /**
@@ -343,6 +345,17 @@ static inline void mds_clear_cpu_buffers
 	asm volatile("verw %[ds]" : : [ds] "m" (ds) : "cc");
 }
 
+/**
+ * mds_user_clear_cpu_buffers - Mitigation for MDS vulnerability
+ *
+ * Clear CPU buffers if the corresponding static key is enabled
+ */
+static inline void mds_user_clear_cpu_buffers(void)
+{
+	if (static_branch_likely(&mds_user_clear))
+		mds_clear_cpu_buffers();
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -63,6 +63,9 @@ DEFINE_STATIC_KEY_FALSE(switch_mm_cond_i
 /* Control unconditional IBPB in switch_mm() */
 DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 
+/* Control MDS CPU buffer clear before returning to user space */
+DEFINE_STATIC_KEY_FALSE(mds_user_clear);
+
 void __init check_bugs(void)
 {
 	identify_boot_cpu();
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -34,6 +34,7 @@
 #include <asm/x86_init.h>
 #include <asm/reboot.h>
 #include <asm/cache.h>
+#include <asm/nospec-branch.h>
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/nmi.h>
@@ -533,6 +534,9 @@ do_nmi(struct pt_regs *regs, long error_
 		write_cr2(this_cpu_read(nmi_cr2));
 	if (this_cpu_dec_return(nmi_state))
 		goto nmi_restart;
+
+	if (user_mode(regs))
+		mds_user_clear_cpu_buffers();
 }
 NOKPROBE_SYMBOL(do_nmi);
 
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -366,6 +366,13 @@ dotraplinkage void do_double_fault(struc
 		regs->ip = (unsigned long)general_protection;
 		regs->sp = (unsigned long)&gpregs->orig_ax;
 
+		/*
+		 * This situation can be triggered by userspace via
+		 * modify_ldt(2) and the return does not take the regular
+		 * user space exit, so a CPU buffer clear is required when
+		 * MDS mitigation is enabled.
+		 */
+		mds_user_clear_cpu_buffers();
 		return;
 	}
 #endif

  parent reply	other threads:[~2019-03-01 23:16 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 21:47 [patch V6 00/14] MDS basics 0 Thomas Gleixner
2019-03-01 21:47 ` [patch V6 01/14] MDS basics 1 Thomas Gleixner
2019-03-02  0:06   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 02/14] MDS basics 2 Thomas Gleixner
2019-03-02  0:34   ` [MODERATED] " Frederic Weisbecker
2019-03-02  8:34   ` Greg KH
2019-03-05 17:54   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 03/14] MDS basics 3 Thomas Gleixner
2019-03-02  1:12   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 04/14] MDS basics 4 Thomas Gleixner
2019-03-02  1:28   ` [MODERATED] " Frederic Weisbecker
2019-03-05 14:52     ` Thomas Gleixner
2019-03-06 20:00   ` [MODERATED] " Andrew Cooper
2019-03-06 20:32     ` Thomas Gleixner
2019-03-07 23:56   ` [MODERATED] " Andi Kleen
2019-03-08  0:36     ` Linus Torvalds
2019-03-01 21:47 ` [patch V6 05/14] MDS basics 5 Thomas Gleixner
2019-03-02  1:37   ` [MODERATED] " Frederic Weisbecker
2019-03-07 23:59   ` Andi Kleen
2019-03-08  6:37     ` Thomas Gleixner
2019-03-01 21:47 ` [patch V6 06/14] MDS basics 6 Thomas Gleixner
2019-03-04  6:28   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 14:55     ` Thomas Gleixner
2019-03-01 21:47 ` Thomas Gleixner [this message]
2019-03-02  2:22   ` [MODERATED] Re: [patch V6 07/14] MDS basics 7 Frederic Weisbecker
2019-03-05 15:30     ` Thomas Gleixner
2019-03-06 15:49       ` [MODERATED] " Frederic Weisbecker
2019-03-06  5:21   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 08/14] MDS basics 8 Thomas Gleixner
2019-03-03  2:54   ` [MODERATED] " Frederic Weisbecker
2019-03-04  6:57   ` [MODERATED] Encrypted Message Jon Masters
2019-03-04  7:06     ` Jon Masters
2019-03-04  8:12       ` Jon Masters
2019-03-05 15:34     ` Thomas Gleixner
2019-03-06 16:21       ` [MODERATED] " Jon Masters
2019-03-06 14:11   ` [MODERATED] Re: [patch V6 08/14] MDS basics 8 Borislav Petkov
2019-03-01 21:47 ` [patch V6 09/14] MDS basics 9 Thomas Gleixner
2019-03-06 16:14   ` [MODERATED] " Frederic Weisbecker
2019-03-01 21:47 ` [patch V6 10/14] MDS basics 10 Thomas Gleixner
2019-03-04  6:45   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 18:42   ` [MODERATED] Re: [patch V6 10/14] MDS basics 10 Andrea Arcangeli
2019-03-06 19:15     ` Thomas Gleixner
2019-03-06 14:31   ` [MODERATED] " Borislav Petkov
2019-03-06 15:30     ` Thomas Gleixner
2019-03-06 18:35       ` Thomas Gleixner
2019-03-06 19:34         ` [MODERATED] Re: " Borislav Petkov
2019-03-01 21:47 ` [patch V6 11/14] MDS basics 11 Thomas Gleixner
2019-03-01 21:47 ` [patch V6 12/14] MDS basics 12 Thomas Gleixner
2019-03-04  5:47   ` [MODERATED] Encrypted Message Jon Masters
2019-03-05 16:04     ` Thomas Gleixner
2019-03-05 16:40   ` [MODERATED] Re: [patch V6 12/14] MDS basics 12 mark gross
2019-03-06 14:42   ` Borislav Petkov
2019-03-01 21:47 ` [patch V6 13/14] MDS basics 13 Thomas Gleixner
2019-03-03  4:01   ` [MODERATED] " Josh Poimboeuf
2019-03-05 16:04     ` Thomas Gleixner
2019-03-05 16:43   ` [MODERATED] " mark gross
2019-03-01 21:47 ` [patch V6 14/14] MDS basics 14 Thomas Gleixner
2019-03-01 23:48 ` [patch V6 00/14] MDS basics 0 Thomas Gleixner
2019-03-04  5:30 ` [MODERATED] Encrypted Message Jon Masters

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=20190301214847.807540001@linutronix.de \
    --to=tglx@linutronix.de \
    --cc=speck@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.