From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use
Date: Fri, 12 Jan 2018 18:01:03 +0000 [thread overview]
Message-ID: <1515780067-31735-14-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1515780067-31735-1-git-send-email-andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
v7:
* static, and tweak comment
---
docs/misc/xen-command-line.markdown | 6 ++-
xen/arch/x86/spec_ctrl.c | 104 ++++++++++++++++++++++++++++++++++--
2 files changed, 105 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index b42abc6..1aa1225 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -246,7 +246,7 @@ enough. Setting this to a high value may cause boot failure, particularly if
the NMI watchdog is also enabled.
### bti (x86)
-> `= List of [ thunk=retpoline|lfence|jmp ]`
+> `= List of [ thunk=retpoline|lfence|jmp, ibrs=<bool> ]`
Branch Target Injection controls. By default, Xen will pick the most
appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -261,6 +261,10 @@ locations. The default thunk is `retpoline` (generally preferred for Intel
hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
overhead), and `lfence` (an `lfence; jmp *%reg` gadget, preferred for AMD).
+On hardware supporting IBRS, the `ibrs=` option can be used to force or
+prevent Xen using the feature itself. If Xen is not using IBRS itself,
+functionality is still set up so IBRS can be virtualised for guests.
+
### xenheap\_megabytes (arm32)
> `= <size>`
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 89e7287..7b0daaf 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -20,6 +20,7 @@
#include <xen/init.h>
#include <xen/lib.h>
+#include <asm/microcode.h>
#include <asm/processor.h>
#include <asm/spec_ctrl.h>
@@ -31,11 +32,12 @@ static enum ind_thunk {
THUNK_LFENCE,
THUNK_JMP,
} opt_thunk __initdata = THUNK_DEFAULT;
+static int opt_ibrs __initdata = -1;
static int __init parse_bti(const char *s)
{
const char *ss;
- int rc = 0;
+ int val, rc = 0;
do {
ss = strchr(s, ',');
@@ -55,6 +57,8 @@ static int __init parse_bti(const char *s)
else
rc = -EINVAL;
}
+ else if ( (val = parse_boolean("ibrs", s, ss)) >= 0 )
+ opt_ibrs = val;
else
rc = -EINVAL;
@@ -91,24 +95,82 @@ static void __init print_details(enum ind_thunk thunk)
printk(XENLOG_DEBUG " Compiled-in support: INDIRECT_THUNK\n");
printk(XENLOG_INFO
- "BTI mitigations: Thunk %s\n",
+ "BTI mitigations: Thunk %s, Others:%s\n",
thunk == THUNK_NONE ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE ? "LFENCE" :
- thunk == THUNK_JMP ? "JMP" : "?");
+ thunk == THUNK_JMP ? "JMP" : "?",
+ boot_cpu_has(X86_FEATURE_XEN_IBRS_SET) ? " IBRS+" :
+ boot_cpu_has(X86_FEATURE_XEN_IBRS_CLEAR) ? " IBRS-" : "");
+}
+
+/* Calculate whether Retpoline is known-safe on this CPU. */
+static bool __init retpoline_safe(void)
+{
+ unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
+
+ if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ return true;
+
+ if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
+ boot_cpu_data.x86 != 6 )
+ return false;
+
+ switch ( boot_cpu_data.x86_model )
+ {
+ case 0x17: /* Penryn */
+ case 0x1d: /* Dunnington */
+ case 0x1e: /* Nehalem */
+ case 0x1f: /* Auburndale / Havendale */
+ case 0x1a: /* Nehalem EP */
+ case 0x2e: /* Nehalem EX */
+ case 0x25: /* Westmere */
+ case 0x2c: /* Westmere EP */
+ case 0x2f: /* Westmere EX */
+ case 0x2a: /* SandyBridge */
+ case 0x2d: /* SandyBridge EP/EX */
+ case 0x3a: /* IvyBridge */
+ case 0x3e: /* IvyBridge EP/EX */
+ case 0x3c: /* Haswell */
+ case 0x3f: /* Haswell EX/EP */
+ case 0x45: /* Haswell D */
+ case 0x46: /* Haswell H */
+ return true;
+
+ /*
+ * Broadwell processors are retpoline-safe after specific microcode
+ * versions.
+ */
+ case 0x3d: /* Broadwell */
+ return ucode_rev >= 0x28;
+ case 0x47: /* Broadwell H */
+ return ucode_rev >= 0x1b;
+ case 0x4f: /* Broadwell EP/EX */
+ return ucode_rev >= 0xb000025;
+ case 0x56: /* Broadwell D */
+ return false; /* TBD. */
+
+ /*
+ * Skylake and later processors are not retpoline-safe.
+ */
+ default:
+ return false;
+ }
}
void __init init_speculation_mitigations(void)
{
enum ind_thunk thunk = THUNK_DEFAULT;
+ bool ibrs = false;
/*
* Has the user specified any custom BTI mitigations? If so, follow their
* instructions exactly and disable all heuristics.
*/
- if ( opt_thunk != THUNK_DEFAULT )
+ if ( opt_thunk != THUNK_DEFAULT || opt_ibrs != -1 )
{
thunk = opt_thunk;
+ ibrs = !!opt_ibrs;
}
else
{
@@ -124,7 +186,21 @@ void __init init_speculation_mitigations(void)
*/
if ( cpu_has_lfence_dispatch )
thunk = THUNK_LFENCE;
+ /*
+ * On Intel hardware, we'd like to use retpoline in preference to
+ * IBRS, but only if it is safe on this hardware.
+ */
+ else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+ {
+ if ( retpoline_safe() )
+ thunk = THUNK_RETPOLINE;
+ else
+ ibrs = true;
+ }
}
+ /* Without compiler thunk support, use IBRS if available. */
+ else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+ ibrs = true;
}
/*
@@ -135,6 +211,13 @@ void __init init_speculation_mitigations(void)
thunk = THUNK_NONE;
/*
+ * If IBRS is in use and thunks are compiled in, there is no point
+ * suffering extra overhead. Switch to the least-overhead thunk.
+ */
+ if ( ibrs && thunk == THUNK_DEFAULT )
+ thunk = THUNK_JMP;
+
+ /*
* If there are still no thunk preferences, the compiled default is
* actually retpoline, and it is better than nothing.
*/
@@ -147,6 +230,19 @@ void __init init_speculation_mitigations(void)
else if ( thunk == THUNK_JMP )
setup_force_cpu_cap(X86_FEATURE_IND_THUNK_JMP);
+ if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+ {
+ /*
+ * Even if we've chosen to not have IBRS set in Xen context, we still
+ * need the IBRS entry/exit logic to virtualise IBRS support for
+ * guests.
+ */
+ if ( ibrs )
+ setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_SET);
+ else
+ setup_force_cpu_cap(X86_FEATURE_XEN_IBRS_CLEAR);
+ }
+
print_details(thunk);
}
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-01-12 18:01 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 18:00 [PATCH v8 00/17] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 01/17] x86: Support compiling with indirect branch thunks Andrew Cooper
2018-01-14 19:48 ` David Woodhouse
2018-01-15 0:00 ` Andrew Cooper
2018-01-15 4:11 ` Konrad Rzeszutek Wilk
2018-01-15 10:14 ` Jan Beulich
2018-01-15 10:40 ` Andrew Cooper
2018-01-15 10:48 ` Jan Beulich
2018-01-12 18:00 ` [PATCH v8 02/17] x86: Support indirect thunks from assembly code Andrew Cooper
2018-01-15 10:28 ` Jan Beulich
2018-01-16 13:55 ` Andrew Cooper
2018-01-16 14:00 ` Jan Beulich
2018-02-04 10:57 ` David Woodhouse
2018-02-05 8:56 ` Jan Beulich
2018-01-12 18:00 ` [PATCH v8 03/17] x86/boot: Report details of speculative mitigations Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 04/17] x86/amd: Try to set lfence as being Dispatch Serialising Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 05/17] x86: Introduce alternative indirect thunks Andrew Cooper
2018-01-15 10:53 ` Jan Beulich
2018-01-12 18:00 ` [PATCH v8 06/17] x86/feature: Definitions for Indirect Branch Controls Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 07/17] x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and IBPB Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 08/17] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests Andrew Cooper
2018-01-16 11:10 ` David Woodhouse
2018-01-16 16:58 ` Andrew Cooper
2018-01-17 9:11 ` Jan Beulich
2018-01-17 9:39 ` Andrew Cooper
2018-01-12 18:00 ` [PATCH v8 09/17] x86/migrate: Move MSR_SPEC_CTRL on migrate Andrew Cooper
2018-01-12 18:01 ` [PATCH v8 10/17] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD} Andrew Cooper
2018-01-15 11:11 ` Jan Beulich
2018-01-15 16:02 ` Boris Ostrovsky
2018-01-16 0:39 ` Tian, Kevin
2018-01-12 18:01 ` [PATCH v8 11/17] x86: Protect unaware domains from meddling hyperthreads Andrew Cooper
2018-01-15 11:26 ` Jan Beulich
2018-01-16 21:11 ` Andrew Cooper
2018-01-17 8:40 ` Jan Beulich
2018-01-17 8:43 ` Andrew Cooper
2018-01-12 18:01 ` [PATCH v8 12/17] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point Andrew Cooper
2018-01-15 12:09 ` Jan Beulich
2018-01-16 21:24 ` Andrew Cooper
2018-01-17 8:47 ` Jan Beulich
2018-01-17 9:25 ` Andrew Cooper
2018-01-12 18:01 ` Andrew Cooper [this message]
2018-01-16 14:10 ` [PATCH v8 13/17] x86/boot: Calculate the most appropriate BTI mitigation to use Boris Ostrovsky
2018-01-16 14:13 ` Andrew Cooper
2018-01-16 14:25 ` Boris Ostrovsky
2018-01-16 15:12 ` Andrew Cooper
2018-01-12 18:01 ` [PATCH v8 14/17] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen Andrew Cooper
2018-01-12 18:01 ` [PATCH v8 15/17] x86/ctxt: Issue a speculation barrier between vcpu contexts Andrew Cooper
2018-01-15 12:54 ` David Woodhouse
2018-01-15 13:02 ` Andrew Cooper
2018-01-15 13:23 ` David Woodhouse
2018-01-15 21:39 ` David Woodhouse
2018-01-17 17:26 ` David Woodhouse
2018-01-18 9:12 ` David Woodhouse
2018-01-12 18:01 ` [PATCH v8 16/17] x86/cpuid: Offer Indirect Branch Controls to guests Andrew Cooper
2018-01-12 18:01 ` [PATCH v8 17/17] x86/idle: Clear SPEC_CTRL while idle Andrew Cooper
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=1515780067-31735-14-git-send-email-andrew.cooper3@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).