From: Norbert Manthey <nmanthey@amazon.de>
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>, Tim Deegan <tim@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Dario Faggioli <dfaggioli@suse.com>,
Martin Pohlack <mpohlack@amazon.de>,
Pawel Wieczorkiewicz <wipawel@amazon.de>,
Julien Grall <julien.grall@arm.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Jan Beulich <jbeulich@suse.com>,
Martin Mazein <amazein@amazon.de>,
Bjoern Doebel <doebel@amazon.de>,
Norbert Manthey <nmanthey@amazon.de>
Subject: [PATCH L1TF v10 1/8] spec: add l1tf-barrier
Date: Thu, 14 Mar 2019 13:50:04 +0100 [thread overview]
Message-ID: <1552567811-5301-2-git-send-email-nmanthey@amazon.de> (raw)
In-Reply-To: <1552567811-5301-1-git-send-email-nmanthey@amazon.de>
To control the runtime behavior on L1TF vulnerable platforms better, the
command line option l1tf-barrier is introduced. This option controls
whether on vulnerable x86 platforms the lfence instruction is used to
prevent speculative execution from bypassing the evaluation of
conditionals that are protected with the evaluate_nospec macro.
By now, Xen is capable of identifying L1TF vulnerable hardware. However,
this information cannot be used for alternative patching, as a CPU feature
is required. To control alternative patching with the command line option,
a new x86 feature "X86_FEATURE_SC_L1TF_VULN" is introduced. This feature
is used to patch the lfence instruction into the arch_barrier_nospec_true
function. The feature is enabled only if L1TF vulnerable hardware is
detected and the command line option does not prevent using this feature.
The status of hyperthreading is considered when automatically enabling
adding the lfence instruction. Since platforms without hyperthreading can
still be vulnerable to L1TF in case the L1 cache is not flushed properly,
the additional lfence instructions are patched in if either hyperthreading
is enabled, or L1 cache flushing is missing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
docs/misc/xen-command-line.pandoc | 14 ++++++++++----
xen/arch/x86/spec_ctrl.c | 17 +++++++++++++++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/spec_ctrl.h | 1 +
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -483,9 +483,9 @@ accounting for hardware capabilities as enumerated via CPUID.
Currently accepted:
-The Speculation Control hardware features `ibrsb`, `stibp`, `ibpb`,
-`l1d-flush` and `ssbd` are used by default if available and applicable. They can
-be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and
+The Speculation Control hardware features `ibrsb`, `stibp`, `ibpb`, `l1d-flush`,
+`l1tf-barrier` and `ssbd` are used by default if available and applicable. They
+can be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and
won't offer them to guests.
### cpuid_mask_cpu
@@ -1902,7 +1902,7 @@ By default SSBD will be mitigated at runtime (i.e `ssbd=runtime`).
### spec-ctrl (x86)
> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu,
-> l1d-flush}=<bool> ]`
+> l1d-flush,l1tf-barrier}=<bool> ]`
Controls for speculative execution sidechannel mitigations. By default, Xen
will pick the most appropriate mitigations based on compiled in support,
@@ -1968,6 +1968,12 @@ Irrespective of Xen's setting, the feature is virtualised for HVM guests to
use. By default, Xen will enable this mitigation on hardware believed to be
vulnerable to L1TF.
+On hardware vulnerable to L1TF, the `l1tf-barrier=` option can be used to force
+or prevent Xen from protecting evaluations inside the hypervisor with a barrier
+instruction to not load potentially secret information into L1 cache. By
+default, Xen will enable this mitigation on hardware believed to be vulnerable
+to L1TF.
+
### sync_console
> `= <boolean>`
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -21,6 +21,7 @@
#include <xen/lib.h>
#include <xen/warning.h>
+#include <asm/cpuid.h>
#include <asm/microcode.h>
#include <asm/msr.h>
#include <asm/processor.h>
@@ -50,6 +51,7 @@ bool __read_mostly opt_ibpb = true;
bool __read_mostly opt_ssbd = false;
int8_t __read_mostly opt_eager_fpu = -1;
int8_t __read_mostly opt_l1d_flush = -1;
+int8_t __read_mostly opt_l1tf_barrier = -1;
bool __initdata bsp_delay_spec_ctrl;
uint8_t __read_mostly default_xen_spec_ctrl;
@@ -91,6 +93,8 @@ static int __init parse_spec_ctrl(const char *s)
if ( opt_pv_l1tf_domu < 0 )
opt_pv_l1tf_domu = 0;
+ opt_l1tf_barrier = 0;
+
disable_common:
opt_rsb_pv = false;
opt_rsb_hvm = false;
@@ -157,6 +161,8 @@ static int __init parse_spec_ctrl(const char *s)
opt_eager_fpu = val;
else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
opt_l1d_flush = val;
+ else if ( (val = parse_boolean("l1tf-barrier", s, ss)) >= 0 )
+ opt_l1tf_barrier = val;
else
rc = -EINVAL;
@@ -248,7 +254,7 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
"\n");
/* Settings for Xen's protection, irrespective of guests. */
- printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s\n",
+ printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s%s\n",
thunk == THUNK_NONE ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE ? "LFENCE" :
@@ -258,7 +264,8 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
!boot_cpu_has(X86_FEATURE_SSBD) ? "" :
(default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
opt_ibpb ? " IBPB" : "",
- opt_l1d_flush ? " L1D_FLUSH" : "");
+ opt_l1d_flush ? " L1D_FLUSH" : "",
+ opt_l1tf_barrier ? " L1TF_BARRIER" : "");
/* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */
if ( cpu_has_bug_l1tf || opt_pv_l1tf_hwdom || opt_pv_l1tf_domu )
@@ -842,6 +849,12 @@ void __init init_speculation_mitigations(void)
else if ( opt_l1d_flush == -1 )
opt_l1d_flush = cpu_has_bug_l1tf && !(caps & ARCH_CAPS_SKIP_L1DFL);
+ /* By default, enable L1TF_VULN on L1TF-vulnerable hardware */
+ if ( opt_l1tf_barrier == -1 )
+ opt_l1tf_barrier = cpu_has_bug_l1tf && (opt_smt || !opt_l1d_flush);
+ if ( opt_l1tf_barrier > 0 )
+ setup_force_cpu_cap(X86_FEATURE_SC_L1TF_VULN);
+
/*
* We do not disable HT by default on affected hardware.
*
diff --git a/xen/include/asm-x86/cpufeatures.h b/xen/include/asm-x86/cpufeatures.h
--- a/xen/include/asm-x86/cpufeatures.h
+++ b/xen/include/asm-x86/cpufeatures.h
@@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP, (FSCAPINTS+0)*32+11) /* SMAP gets used by Xen it
XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /* lfence set as Dispatch Serialising */
XEN_CPUFEATURE(IND_THUNK_LFENCE,(FSCAPINTS+0)*32+13) /* Use IND_THUNK_LFENCE */
XEN_CPUFEATURE(IND_THUNK_JMP, (FSCAPINTS+0)*32+14) /* Use IND_THUNK_JMP */
+XEN_CPUFEATURE(SC_L1TF_VULN, (FSCAPINTS+0)*32+15) /* L1TF protection required */
XEN_CPUFEATURE(SC_MSR_PV, (FSCAPINTS+0)*32+16) /* MSR_SPEC_CTRL used by Xen for PV */
XEN_CPUFEATURE(SC_MSR_HVM, (FSCAPINTS+0)*32+17) /* MSR_SPEC_CTRL used by Xen for HVM */
XEN_CPUFEATURE(SC_RSB_PV, (FSCAPINTS+0)*32+18) /* RSB overwrite needed for PV */
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -37,6 +37,7 @@ extern bool opt_ibpb;
extern bool opt_ssbd;
extern int8_t opt_eager_fpu;
extern int8_t opt_l1d_flush;
+extern int8_t opt_l1tf_barrier;
extern bool bsp_delay_spec_ctrl;
extern uint8_t default_xen_spec_ctrl;
--
2.7.4
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-03-14 12:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 12:50 L1TF Patch Series v10 Norbert Manthey
2019-03-14 12:50 ` Norbert Manthey [this message]
2019-03-14 12:50 ` [PATCH L1TF v10 2/8] nospec: introduce evaluate_nospec Norbert Manthey
2019-03-14 13:19 ` Jan Beulich
2019-03-14 13:21 ` Norbert Manthey
2019-03-14 12:50 ` [PATCH L1TF v10 3/8] is_control_domain: block speculation Norbert Manthey
2019-03-14 12:50 ` [PATCH L1TF v10 4/8] is_hvm/pv_domain: " Norbert Manthey
2019-04-05 15:34 ` Andrew Cooper
2019-04-05 15:34 ` [Xen-devel] " Andrew Cooper
2019-04-05 18:29 ` Norbert Manthey
2019-04-05 18:29 ` [Xen-devel] " Norbert Manthey
2019-04-05 18:38 ` Andrew Cooper
2019-04-05 18:38 ` [Xen-devel] " Andrew Cooper
2019-04-08 9:19 ` Jan Beulich
2019-04-08 9:19 ` [Xen-devel] " Jan Beulich
2019-03-14 12:50 ` [PATCH L1TF v10 5/8] common/memory: block speculative out-of-bound accesses Norbert Manthey
2019-03-14 12:50 ` [PATCH L1TF v10 6/8] x86/hvm: add nospec to hvmop param Norbert Manthey
2019-03-14 12:50 ` [PATCH L1TF v10 7/8] common/grant_table: block speculative out-of-bound accesses Norbert Manthey
2019-03-29 17:11 ` Jan Beulich
2019-05-20 14:27 ` Norbert Manthey
2019-05-20 14:27 ` [Xen-devel] " Norbert Manthey
2019-05-21 9:41 ` Jan Beulich
2019-05-21 9:41 ` [Xen-devel] " Jan Beulich
2019-03-14 12:50 ` [PATCH L1TF v10 8/8] common/domain: " Norbert Manthey
2019-03-14 13:20 ` 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=1552567811-5301-2-git-send-email-nmanthey@amazon.de \
--to=nmanthey@amazon.de \
--cc=George.Dunlap@eu.citrix.com \
--cc=amazein@amazon.de \
--cc=andrew.cooper3@citrix.com \
--cc=dfaggioli@suse.com \
--cc=doebel@amazon.de \
--cc=dwmw@amazon.co.uk \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=julien.grall@arm.com \
--cc=konrad.wilk@oracle.com \
--cc=mpohlack@amazon.de \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=wipawel@amazon.de \
--cc=xen-devel@lists.xenproject.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).