mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: linux-kernel@vger.kernel.org
Cc: Dave Hansen
	<dave.hansen@linux.intel.com>,torvalds@linux-foundation.org,tglx@linutronix.de,gnomes@lxorguk.ukuu.org.uk,riel@redhat.com,jpoimboe@redhat.com,thomas.lendacky@amd.com,peterz@infradead.org,jikos@kernel.org,luto@amacapital.net,keescook@google.com,gregkh@linux-foundation.org,pjt@google.com,dwmw@amazon.co.uk,x86@kernel.org,ak@linux.intel.com,tim.c.chen@linux.intel.com,arjan@linux.intel.com,dan.j.williams@intel.com,asit.k.mallick@intel.com
Subject: [RFC][PATCH] x86: proposed new ARCH_CAPABILITIES MSR bit for RSB-underflow
Date: Fri, 16 Feb 2018 11:17:55 -0800	[thread overview]
Message-ID: <20180216191755.6F62DDEA@viggo.jf.intel.com> (raw)


Intel is considering adding a new bit to the IA32_ARCH_CAPABILITIES
MSR to tell when RSB underflow might be happen.  Feedback on this
would be greatly appreciated before the specification is finalized.

---

Background:

The RSB is a microarchitectural structure that attempts to help
predict the branch target of RET instructions.  It is implemented as a
stack that is pushed on CALL and popped on RET.  Being a stack, it can
become empty.  On some processors, an empty condition leads to use of
the other indirect branch predictors which have been targeted by
Spectre variant 2 (branch target injection) exploits.

Processors based on Skylake and its close derivatives have this
fallback behavior and need additional mitigation to avoid RSB-empty
conditions.  Right now, the only place we do this "RSB stuffing"
operation is at context switch.  We currently have a model/family list
to decide where to deploy this.

Problem:

However, that causes a problem in virtualization environments.  They
routinely expose a different model/family to guests than what the
bare-metal hardware has.  This, among other things, makes it easy to
migrate guests between different bare-metal systems with different
capabilities.  However, this defeats the Skylake-generation
model/family detection.

Solution:

To help address this issue, Intel is proposing a new bit in the
IA32_ARCH_CAPABILITIES MSR.  This bit, "RSB Override" (RSBO) would
indicate:

	The CPU may predict the target of RET instructions with a
	predictor other than the RSB when the RSB is 'empty'.

Hardware implementations may choose to set this, but it can also be
set by a hypervisor that traps RDMSR and simply wants to indicate to a
guest that it should deploy RSB-underflow mitigations.

An OS should assume that RSB-underflow mitigations are needed both
when RSBO=1 or when running on Skylake-generation processors with
RSBO=0.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel <riel@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: thomas.lendacky@amd.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Kees Cook <keescook@google.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Cc: Paul Turner <pjt@google.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: x86@kernel.org
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>

---

 b/arch/x86/include/asm/msr-index.h |    1 
 b/arch/x86/kernel/cpu/bugs.c       |   47 +++++++++++++++++++++++++++++++++----
 2 files changed, 43 insertions(+), 5 deletions(-)

diff -puN arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing arch/x86/kernel/cpu/bugs.c
--- a/arch/x86/kernel/cpu/bugs.c~need-rsb-stuffing	2018-02-16 10:06:56.807610157 -0800
+++ b/arch/x86/kernel/cpu/bugs.c	2018-02-16 10:43:24.281604702 -0800
@@ -218,6 +218,43 @@ static bool __init is_skylake_era(void)
 	return false;
 }
 
+/*
+ * This MSR has a bit to indicate whether the processor might fall back to
+ * the BTB.  Hypervisors might lie about the model/family, breaking the
+ * is_skylake_era() check.  They might also want the OS to deploy
+ * mitigations because it *might* get migrated to other hardware that has
+ * this behavior, even if current bare-metal hardware is not exposed.
+ */
+static bool cpu_has_rsb_override(void)
+{
+	u64 ia32_cap = 0;
+
+        if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
+		rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
+
+        /* RSBO == RSB Override */
+        if (ia32_cap & ARCH_CAP_RSBO)
+		return true;
+
+	return false;
+}
+
+/*
+ * Can a RET instruction on this CPU fall back to the BTB?
+ */
+static bool __init cpu_ret_uses_btb(void)
+{
+	/* All Skylake-era processors fall back to BTB */
+	if (is_skylake_era())
+		return true;
+
+	/* Does the ARCH_CAPABILITIES override the model/family we see? */
+	if (cpu_has_rsb_override())
+		return true;
+
+	return false;
+}
+
 static void __init spectre_v2_select_mitigation(void)
 {
 	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -283,14 +320,14 @@ retpoline_auto:
 	 * from a shallow call stack to a deeper one. To prevent this fill
 	 * the entire RSB, even when using IBRS.
 	 *
-	 * Skylake era CPUs have a separate issue with *underflow* of the
-	 * RSB, when they will predict 'ret' targets from the generic BTB.
-	 * The proper mitigation for this is IBRS. If IBRS is not supported
-	 * or deactivated in favour of retpolines the RSB fill on context
+	 * Some CPUs have a separate issue with *underflow* of the RSB,
+	 * when they will predict 'ret' targets from the generic BTB.  The
+	 * proper mitigation for this is IBRS. If IBRS is not supported or
+	 * deactivated in favour of retpolines the RSB fill on context
 	 * switch is required.
 	 */
 	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
+	     !boot_cpu_has(X86_FEATURE_SMEP)) || cpu_ret_uses_btb()) {
 		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
 		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
 	}
diff -puN arch/x86/include/asm/msr-index.h~need-rsb-stuffing arch/x86/include/asm/msr-index.h
--- a/arch/x86/include/asm/msr-index.h~need-rsb-stuffing	2018-02-16 10:10:25.738609636 -0800
+++ b/arch/x86/include/asm/msr-index.h	2018-02-16 10:12:22.880609344 -0800
@@ -68,6 +68,7 @@
 #define MSR_IA32_ARCH_CAPABILITIES	0x0000010a
 #define ARCH_CAP_RDCL_NO		(1 << 0)   /* Not susceptible to Meltdown */
 #define ARCH_CAP_IBRS_ALL		(1 << 1)   /* Enhanced IBRS support */
+#define ARCH_CAP_RSBO			(1 << 2)   /* Needs RSB Stuffing */
 
 #define MSR_IA32_BBL_CR_CTL		0x00000119
 #define MSR_IA32_BBL_CR_CTL3		0x0000011e
_

             reply	other threads:[~2018-02-16 19:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 19:17 Dave Hansen [this message]
2018-02-16 19:38 ` Linus Torvalds
2018-02-16 19:43   ` Linus Torvalds
2018-02-16 19:47     ` Arjan van de Ven
2018-02-19 14:21 ` Woodhouse, David

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=20180216191755.6F62DDEA@viggo.jf.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linux-foundation.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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 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®