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@xxxxxxxxxx>
---
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Wei Liu <wl@xxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Juergen Gross <jgross@xxxxxxxx>
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.
