| Message ID | 20191023135812.21348-5-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Unbreak evaluate_nospec() and livepatching | expand |
On 23.10.19 15:58, Andrew Cooper wrote: > l1tf-barrier is an inappropriate name, and came about because of restrictions > on could be discussed publicly when the patches were proposed. > > In practice, it is for general Spectre v1 mitigations, and is necessary in all > cases. An adversary which can control speculation in Xen can leak data in > cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not > limited to just L1TF with HT active. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Juergen Gross <jgross@suse.com> ... one nit below. > --- > CC: Jan Beulich <JBeulich@suse.com> > CC: Wei Liu <wl@xen.org> > CC: Roger Pau Monné <roger.pau@citrix.com> > CC: Juergen Gross <jgross@suse.com> > > v3: > * New > > In principle it should be tristate and being disabled by default on parts > which don't speculate, but it is too late in 4.13 to organise this. > --- > docs/misc/xen-command-line.pandoc | 11 +++++------ > xen/arch/x86/spec_ctrl.c | 17 +++++++---------- > xen/include/asm-x86/cpufeatures.h | 2 +- > xen/include/asm-x86/nospec.h | 2 +- > xen/include/asm-x86/spec_ctrl.h | 2 +- > 5 files changed, 15 insertions(+), 19 deletions(-) > > diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc > index 67df80c50d..e37a13ed11 100644 > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -1960,7 +1960,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,md-clear}=<bool>, > > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu, > -> l1d-flush,l1tf-barrier}=<bool> ]` > +> l1d-flush,branch-harden}=<bool> ]` > > Controls for speculative execution sidechannel mitigations. By default, Xen > will pick the most appropriate mitigations based on compiled in support, > @@ -2032,11 +2032,10 @@ 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. > +If Xen is compiled with `CONFIG_SPECULATIVE_HARDEN_BRANCH`, the > +`branch-harden=` boolean can be used to force or prevent Xen from using > +speculation barriers to protect selected conditional branches. By default, > +Xen will enabled this mitigation. s/enabled/enable/ Juergen
On 23.10.2019 15:58, Andrew Cooper wrote: > l1tf-barrier is an inappropriate name, and came about because of restrictions > on could be discussed publicly when the patches were proposed. > > In practice, it is for general Spectre v1 mitigations, and is necessary in all > cases. An adversary which can control speculation in Xen can leak data in > cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not > limited to just L1TF with HT active. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> > In principle it should be tristate and being disabled by default on parts > which don't speculate, but it is too late in 4.13 to organise this. And the fundamental issue is correctly compiling the conditions under which to default to true and false respectively? I ask because if it was not this then I wouldn't see what hindering factor there is to make this tristate right away. Jan
On 25/10/2019 13:09, Jan Beulich wrote: > On 23.10.2019 15:58, Andrew Cooper wrote: >> l1tf-barrier is an inappropriate name, and came about because of restrictions >> on could be discussed publicly when the patches were proposed. >> >> In practice, it is for general Spectre v1 mitigations, and is necessary in all >> cases. An adversary which can control speculation in Xen can leak data in >> cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not >> limited to just L1TF with HT active. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> > Reviewed-by: Jan Beulich <jbeulich@suse.com> > >> In principle it should be tristate and being disabled by default on parts >> which don't speculate, but it is too late in 4.13 to organise this. > And the fundamental issue is correctly compiling the conditions under which > to default to true and false respectively? Yes. > I ask because if it was not this > then I wouldn't see what hindering factor there is to make this tristate > right away. Linux's NO_SPECULATION list is a start (if there is actually an intersection with 64bit capable CPUs), but there are mitigating factors on some later CPUs as well. ~Andrew
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 67df80c50d..e37a13ed11 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1960,7 +1960,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,md-clear}=<bool>, > bti-thunk=retpoline|lfence|jmp, {ibrs,ibpb,ssbd,eager-fpu, -> l1d-flush,l1tf-barrier}=<bool> ]` +> l1d-flush,branch-harden}=<bool> ]` Controls for speculative execution sidechannel mitigations. By default, Xen will pick the most appropriate mitigations based on compiled in support, @@ -2032,11 +2032,10 @@ 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. +If Xen is compiled with `CONFIG_SPECULATIVE_HARDEN_BRANCH`, the +`branch-harden=` boolean can be used to force or prevent Xen from using +speculation barriers to protect selected conditional branches. By default, +Xen will enabled this mitigation. ### sync_console > `= <boolean>` diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c index ee5439a371..e74e0cc619 100644 --- a/xen/arch/x86/spec_ctrl.c +++ b/xen/arch/x86/spec_ctrl.c @@ -52,7 +52,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 __read_mostly opt_branch_harden = true; bool __initdata bsp_delay_spec_ctrl; uint8_t __read_mostly default_xen_spec_ctrl; @@ -97,7 +97,7 @@ static int __init parse_spec_ctrl(const char *s) if ( opt_pv_l1tf_domu < 0 ) opt_pv_l1tf_domu = 0; - opt_l1tf_barrier = 0; + opt_branch_harden = false; disable_common: opt_rsb_pv = false; @@ -174,8 +174,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 if ( (val = parse_boolean("branch-harden", s, ss)) >= 0 ) + opt_branch_harden = val; else rc = -EINVAL; @@ -348,7 +348,7 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps) opt_ibpb ? " IBPB" : "", opt_l1d_flush ? " L1D_FLUSH" : "", opt_md_clear_pv || opt_md_clear_hvm ? " VERW" : "", - opt_l1tf_barrier ? " L1TF_BARRIER" : ""); + opt_branch_harden ? " BRANCH_HARDEN" : ""); /* L1TF diagnostics, printed if vulnerable or PV shadowing is in use. */ if ( cpu_has_bug_l1tf || opt_pv_l1tf_hwdom || opt_pv_l1tf_domu ) @@ -1033,11 +1033,8 @@ 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); + if ( opt_branch_harden ) + setup_force_cpu_cap(X86_FEATURE_SC_BRANCH_HARDEN); /* * 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 index 91eccf5161..b9d3cac975 100644 --- a/xen/include/asm-x86/cpufeatures.h +++ b/xen/include/asm-x86/cpufeatures.h @@ -27,7 +27,7 @@ XEN_CPUFEATURE(XEN_SMAP, X86_SYNTH(11)) /* SMAP gets used by Xen itself XEN_CPUFEATURE(LFENCE_DISPATCH, X86_SYNTH(12)) /* lfence set as Dispatch Serialising */ XEN_CPUFEATURE(IND_THUNK_LFENCE, X86_SYNTH(13)) /* Use IND_THUNK_LFENCE */ XEN_CPUFEATURE(IND_THUNK_JMP, X86_SYNTH(14)) /* Use IND_THUNK_JMP */ -XEN_CPUFEATURE(SC_L1TF_VULN, X86_SYNTH(15)) /* L1TF protection required */ +XEN_CPUFEATURE(SC_BRANCH_HARDEN, X86_SYNTH(15)) /* Conditional Branch Hardening */ XEN_CPUFEATURE(SC_MSR_PV, X86_SYNTH(16)) /* MSR_SPEC_CTRL used by Xen for PV */ XEN_CPUFEATURE(SC_MSR_HVM, X86_SYNTH(17)) /* MSR_SPEC_CTRL used by Xen for HVM */ XEN_CPUFEATURE(SC_RSB_PV, X86_SYNTH(18)) /* RSB overwrite needed for PV */ diff --git a/xen/include/asm-x86/nospec.h b/xen/include/asm-x86/nospec.h index 154e92aed8..f6eb84eee5 100644 --- a/xen/include/asm-x86/nospec.h +++ b/xen/include/asm-x86/nospec.h @@ -10,7 +10,7 @@ static always_inline bool barrier_nospec_true(void) { #ifdef CONFIG_SPECULATIVE_HARDEN_BRANCH - alternative("", "lfence", X86_FEATURE_SC_L1TF_VULN); + alternative("", "lfence", X86_FEATURE_SC_BRANCH_HARDEN); #endif return true; } diff --git a/xen/include/asm-x86/spec_ctrl.h b/xen/include/asm-x86/spec_ctrl.h index 1339ddd7ef..9caecddfec 100644 --- a/xen/include/asm-x86/spec_ctrl.h +++ b/xen/include/asm-x86/spec_ctrl.h @@ -37,7 +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 opt_branch_harden; extern bool bsp_delay_spec_ctrl; extern uint8_t default_xen_spec_ctrl;
l1tf-barrier is an inappropriate name, and came about because of restrictions on could be discussed publicly when the patches were proposed. In practice, it is for general Spectre v1 mitigations, and is necessary in all cases. An adversary which can control speculation in Xen can leak data in cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not limited to just L1TF with HT active. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Wei Liu <wl@xen.org> CC: Roger Pau Monné <roger.pau@citrix.com> CC: Juergen Gross <jgross@suse.com> v3: * New In principle it should be tristate and being disabled by default on parts which don't speculate, but it is too late in 4.13 to organise this. --- docs/misc/xen-command-line.pandoc | 11 +++++------ xen/arch/x86/spec_ctrl.c | 17 +++++++---------- xen/include/asm-x86/cpufeatures.h | 2 +- xen/include/asm-x86/nospec.h | 2 +- xen/include/asm-x86/spec_ctrl.h | 2 +- 5 files changed, 15 insertions(+), 19 deletions(-)