[v3,4/7] x86/nospec: Rename and rework l1tf-barrier as branch-harden
diff mbox series

Message ID 20191023135812.21348-5-andrew.cooper3@citrix.com
State New, archived
Headers show
Series
  • Unbreak evaluate_nospec() and livepatching
Related show

Commit Message

Andrew Cooper Oct. 23, 2019, 1:58 p.m. UTC
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(-)

Comments

Jürgen Groß Oct. 23, 2019, 2:43 p.m. UTC | #1
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
Jan Beulich Oct. 25, 2019, 12:09 p.m. UTC | #2
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
Andrew Cooper Oct. 29, 2019, 5 p.m. UTC | #3
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

Patch
diff mbox series

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;