|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] [xen stable-4.6] x86/spec-ctrl: Introduce an option to control L1D_FLUSH for HVM HAP guests
commit 4b12b44b21a9d724beaff3330bfd2db57640e416
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Tue May 29 18:44:16 2018 +0100
Commit: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CommitDate: Tue Aug 14 17:39:57 2018 +0100
x86/spec-ctrl: Introduce an option to control L1D_FLUSH for HVM HAP guests
This mitigation requires up-to-date microcode, and is enabled by default on
affected hardware if available, and is used for HVM guests
The default for SMT/Hyperthreading is far more complicated to reason about,
not least because we don't know if the user is going to want to run any HVM
guests to begin with. If a explicit default isn't given, nag the user to
perform a risk assessment and choose an explicit default, and leave other
configuration to the toolstack.
This is part of XSA-273 / CVE-2018-3620.
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
(cherry picked from commit 3bd36952dab60290f33d6791070b57920e10754b)
---
docs/misc/xen-command-line.markdown | 9 ++++++++-
xen/arch/x86/hvm/vmx/vmcs.c | 5 +++++
xen/arch/x86/spec_ctrl.c | 40 +++++++++++++++++++++++++++++++++++--
xen/include/asm-x86/hvm/vmx/vmcs.h | 13 ++++++++++++
xen/include/asm-x86/spec_ctrl.h | 1 +
5 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 4b6532e99b..ff80b2c85a 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1466,7 +1466,8 @@ false disable the quirk workaround, which is also the
default.
### spec-ctrl (x86)
> `= List of [ <bool>, xen=<bool>, {pv,hvm,msr-sc,rsb}=<bool>,
-> bti-thunk=retpoline|lfence|jmp,
{ibrs,ibpb,ssbd,eager-fpu}=<bool> ]`
+> bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu,
+> l1d-flush}=<bool> ]`
Controls for speculative execution sidechannel mitigations. By default, Xen
will pick the most appropriate mitigations based on compiled in support,
@@ -1521,6 +1522,12 @@ from using fully eager FPU context switches. This is
currently implemented as
a global control. By default, Xen will choose to use fully eager context
switches on hardware believed to speculate past #NM exceptions.
+On hardware supporting L1D_FLUSH, the `l1d-flush=` option can be used to force
+or prevent Xen from issuing an L1 data cache flush on each VMEntry.
+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.
+
### sync\_console
> `= <boolean>`
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index e99c0a54a2..3d88145274 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -38,6 +38,7 @@
#include <asm/hvm/vmx/vmcs.h>
#include <asm/flushtlb.h>
#include <asm/shadow.h>
+#include <asm/spec_ctrl.h>
#include <asm/tboot.h>
static bool_t __read_mostly opt_vpid_enabled = 1;
@@ -1281,6 +1282,10 @@ static int construct_vmcs(struct vcpu *v)
vmx_vlapic_msr_changed(v);
}
+ if ( opt_l1d_flush && paging_mode_hap(d) )
+ rc = vmx_add_msr(v, MSR_FLUSH_CMD, VMX_MSR_GUEST_LOADONLY)
+ ?: vmx_write_guest_loadonly_msr(v, MSR_FLUSH_CMD, FLUSH_CMD_L1D);
+
out:
vmx_vmcs_exit(v);
diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 5b839022b1..2040776e85 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -23,6 +23,7 @@
#include <asm/microcode.h>
#include <asm/msr.h>
#include <asm/processor.h>
+#include <asm/setup.h>
#include <asm/spec_ctrl.h>
#include <asm/spec_ctrl_asm.h>
@@ -45,6 +46,7 @@ static int8_t __initdata opt_ibrs = -1;
bool_t __read_mostly opt_ibpb = 1;
bool_t __read_mostly opt_ssbd = 0;
int8_t __read_mostly opt_eager_fpu = -1;
+int8_t __read_mostly opt_l1d_flush = -1;
bool_t __initdata bsp_delay_spec_ctrl;
uint8_t __read_mostly default_xen_spec_ctrl;
@@ -122,6 +124,7 @@ static int __init parse_spec_ctrl(char *s)
opt_ibrs = 0;
opt_ibpb = 0;
opt_ssbd = 0;
+ opt_l1d_flush = 0;
}
else if ( val > 0 )
rc = -EINVAL;
@@ -177,6 +180,8 @@ static int __init parse_spec_ctrl(char *s)
opt_ssbd = val;
else if ( (val = parse_boolean("eager-fpu", s, ss)) >= 0 )
opt_eager_fpu = val;
+ else if ( (val = parse_boolean("l1d-flush", s, ss)) >= 0 )
+ opt_l1d_flush = val;
else
rc = -EINVAL;
@@ -274,7 +279,7 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
#endif
/* Settings for Xen's protection, irrespective of guests. */
- printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s\n",
+ printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s\n",
thunk == THUNK_NONE ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE ? "LFENCE" :
@@ -283,7 +288,8 @@ static void __init print_details(enum ind_thunk thunk,
uint64_t caps)
(default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
!boot_cpu_has(X86_FEATURE_SSBD) ? "" :
(default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
- opt_ibpb ? " IBPB" : "");
+ opt_ibpb ? " IBPB" : "",
+ opt_l1d_flush ? " L1D_FLUSH" : "");
/* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */
if ( cpu_has_bug_l1tf || opt_pv_l1tf )
@@ -855,6 +861,36 @@ void __init init_speculation_mitigations(void)
opt_pv_l1tf = OPT_PV_L1TF_DOMU;
}
+ /*
+ * By default, enable L1D_FLUSH on L1TF-vulnerable hardware, unless
+ * instructed to skip the flush on vmentry by our outer hypervisor.
+ */
+ if ( !boot_cpu_has(X86_FEATURE_L1D_FLUSH) )
+ opt_l1d_flush = 0;
+ else if ( opt_l1d_flush == -1 )
+ opt_l1d_flush = cpu_has_bug_l1tf && !(caps & ARCH_CAPS_SKIP_L1DFL);
+
+ /*
+ * We do not disable HT by default on affected hardware.
+ *
+ * Firstly, if the user intends to use exclusively PV, or HVM shadow
+ * guests, HT isn't a concern and should remain fully enabled. Secondly,
+ * safety for HVM HAP guests can be arranged by the toolstack with core
+ * parking, pinning or cpupool configurations, including mixed setups.
+ *
+ * However, if we are on affected hardware, with HT enabled, and the user
+ * hasn't explicitly chosen whether to use HT or not, nag them to do so.
+ */
+ if ( opt_smt == -1 && cpu_has_bug_l1tf &&
+ boot_cpu_data.x86_num_siblings > 1 )
+ {
+ printk("******************************************************\n");
+ printk("Booted on L1TF-vulnerable hardware with SMT/Hyperthreading\n");
+ printk("enabled. Please assess your configuration and choose an\n");
+ printk("explicit 'smt=<bool>' setting. See XSA-273.\n");
+ printk("******************************************************\n");
+ }
+
print_details(thunk, caps);
/*
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index 8aefe89f20..76549e811d 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -554,6 +554,19 @@ static inline int vmx_write_guest_msr(struct vcpu *v,
uint32_t msr,
return 0;
}
+static inline int vmx_write_guest_loadonly_msr(struct vcpu *v, uint32_t msr,
+ uint64_t val)
+{
+ struct vmx_msr_entry *ent = vmx_find_msr(v, msr, VMX_MSR_GUEST_LOADONLY);
+
+ if ( !ent )
+ return -ESRCH;
+
+ ent->data = val;
+
+ return 0;
+}
+
void vmx_disable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
void vmx_enable_intercept_for_msr(struct vcpu *v, u32 msr, int type);
void vmx_vmcs_switch(struct vmcs_struct *from, struct vmcs_struct *to);
diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h
index 4d21e434e4..ee7f18d52d 100644
--- a/xen/include/asm-x86/spec_ctrl.h
+++ b/xen/include/asm-x86/spec_ctrl.h
@@ -29,6 +29,7 @@ void init_speculation_mitigations(void);
extern bool_t opt_ibpb;
extern bool_t opt_ssbd;
extern int8_t opt_eager_fpu;
+extern int8_t opt_l1d_flush;
extern bool_t bsp_delay_spec_ctrl;
extern uint8_t default_xen_spec_ctrl;
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.6
_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |