From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v6.5 22/26] x86/boot: Calculate the most appropriate BTI mitigation to use
Date: Thu, 4 Jan 2018 00:15:51 +0000 [thread overview]
Message-ID: <1515024955-13390-23-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1515024955-13390-1-git-send-email-andrew.cooper3@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
v4:
* New
v5:
* Whitespace fixes
---
docs/misc/xen-command-line.markdown | 6 ++-
xen/arch/x86/spec_ctrl.c | 103 ++++++++++++++++++++++++++++++++++--
2 files changed, 104 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index 19e12ac..3429484 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|plain ]`
+> `= List of [ thunk=retpoline|lfence|plain, ibrs=<bool> ]`
Branch Target Injection controls. By default, Xen will pick the most
appropriate BTI mitigations based on compiled in support, loaded microcode,
@@ -259,6 +259,10 @@ select which of the thunks gets patched into the `__x86.indirect_thunk.%reg`
locations. The default thunk is `retpoline`, with the alternatives being
`plain` (a `jmp *%reg` gadget), and `lfence` (an `lfence; jmp *%reg` gadget).
+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 d9ace2d..1cccb8a 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 @@ enum ind_thunk {
THUNK_LFENCE,
THUNK_JMP,
} opt_thunk __initdata = THUNK_DEFAULT;
+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,18 @@ void __init init_speculation_mitigations(void)
else if ( thunk == THUNK_JMP )
setup_force_cpu_cap(X86_FEATURE_IND_THUNK_JMP);
+ /*
+ * Even if we've chosen not to use IBRS for Xen itself, we still need the
+ * IBRS entry/exit logic to virtualise IBRS support for guests.
+ */
+ if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+ {
+ 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-04 0:15 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 0:15 [PATCH v6.5 00/26] x86: Mitigations for SP2/CVE-2017-5715/Branch Target Injection Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 01/26] x86/alt: Break out alternative-asm into a separate header file Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 02/26] x86/alt: Introduce ALTERNATIVE{, _2} macros Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 03/26] x86/hvm: Rename update_guest_vendor() callback to cpuid_policy_changed() Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 04/26] x86: Introduce a common cpuid_policy_updated() Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 05/26] x86/entry: Remove support for partial cpu_user_regs frames Andrew Cooper
2018-01-04 8:51 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 06/26] x86/entry: Rearrange RESTORE_ALL to restore register in stack order Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 07/26] x86/hvm: Use SAVE_ALL to construct the cpu_user_regs frame after VMExit Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 08/26] x86/entry: Erase guest GPR state on entry to Xen Andrew Cooper
2018-01-22 10:04 ` David Woodhouse
2018-01-22 10:18 ` Andrew Cooper
2018-01-22 10:27 ` David Woodhouse
2018-01-04 0:15 ` [PATCH v6.5 09/26] x86: Support compiling with indirect branch thunks Andrew Cooper
2018-01-04 9:02 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 10/26] common/wait: Clarifications to wait infrastructure Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 11/26] x86: Support indirect thunks from assembly code Andrew Cooper
2018-01-04 9:23 ` Jan Beulich
2018-01-08 18:24 ` Andrew Cooper
2018-01-09 8:36 ` Jan Beulich
2018-01-09 11:23 ` Andrew Cooper
2018-01-09 13:18 ` Jan Beulich
2018-01-11 13:03 ` David Woodhouse
2018-01-11 13:41 ` Andrew Cooper
2018-01-11 13:46 ` David Woodhouse
2018-01-04 0:15 ` [PATCH v6.5 12/26] x86/boot: Report details of speculative mitigations Andrew Cooper
2018-01-04 9:29 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 13/26] x86/amd: Try to set lfence as being Dispatch Serialising Andrew Cooper
2018-01-04 9:32 ` Jan Beulich
2018-01-08 19:01 ` Andrew Cooper
2018-01-09 8:38 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 14/26] x86: Introduce alternative indirect thunks Andrew Cooper
2018-01-04 9:40 ` Jan Beulich
2018-01-09 11:44 ` Andrew Cooper
2018-01-09 13:24 ` Jan Beulich
2018-01-09 13:30 ` Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 15/26] x86/feature: Definitions for Indirect Branch Controls Andrew Cooper
2018-01-04 1:14 ` Doug Goldstein
2018-01-04 1:16 ` Andrew Cooper
2018-01-04 4:05 ` Anthony Liguori
2018-01-04 9:42 ` Jan Beulich
2018-01-04 18:51 ` Wei Liu
2018-01-04 0:15 ` [PATCH v6.5 16/26] x86/cmdline: Introduce a command line option to disable IBRS/IBPB, STIBP and IBPB Andrew Cooper
2018-01-04 9:43 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 17/26] x86/msr: Emulation of MSR_{SPEC_CTRL, PRED_CMD} for guests Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 18/26] x86/migrate: Move MSR_SPEC_CTRL on migrate Andrew Cooper
2018-01-04 0:15 ` [PATCH v6.5 19/26] x86/hvm: Permit guests direct access to MSR_{SPEC_CTRL, PRED_CMD} Andrew Cooper
2018-01-04 9:52 ` Jan Beulich
2018-01-09 12:03 ` Andrew Cooper
2018-01-09 13:28 ` Jan Beulich
2018-01-09 13:34 ` Andrew Cooper
2018-01-09 13:58 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 20/26] x86: Protect unaware domains from meddling hyperthreads Andrew Cooper
2018-01-04 9:59 ` Jan Beulich
2018-01-09 14:21 ` Andrew Cooper
2018-01-09 14:29 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 21/26] x86/entry: Use MSR_SPEC_CTRL at each entry/exit point Andrew Cooper
2018-01-04 10:14 ` Jan Beulich
2018-01-04 0:15 ` Andrew Cooper [this message]
2018-01-04 10:17 ` [PATCH v6.5 22/26] x86/boot: Calculate the most appropriate BTI mitigation to use Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 23/26] x86/entry: Clobber the Return Stack Buffer on entry to Xen Andrew Cooper
2018-01-04 10:22 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 24/26] x86/ctxt: Issue a speculation barrier between vcpu contexts Andrew Cooper
2018-01-04 10:25 ` Jan Beulich
2018-01-04 0:15 ` [PATCH v6.5 25/26] x86/cpuid: Offer Indirect Branch Controls to guests Andrew Cooper
2018-01-09 11:44 ` Wei Liu
2018-01-04 0:15 ` [PATCH v6.5 26/26] x86/idle: Clear SPEC_CTRL while idle Andrew Cooper
2018-01-04 10:29 ` Jan Beulich
2018-01-04 10:41 ` Jan Beulich
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=1515024955-13390-23-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).