File xsa305-2.patch of Package xen.14030
x86/spec-ctrl: Mitigate the TSX Asynchronous Abort sidechannel
See patch documentation and comments.
This is part of XSA-305 / CVE-2019-11135
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1375,7 +1375,7 @@ extreme care.**
An overall boolean value, `spec-ctrl=no`, can be specified to turn off all
mitigations, including pieces of infrastructure used to virtualise certain
mitigation features for guests. This also includes settings which `xpti`,
-`smt`, `pv-l1tf` control, unless the respective option(s) have been
+`smt`, `pv-l1tf`, `tsx` control, unless the respective option(s) have been
specified earlier on the command line.
Alternatively, a slightly more restricted `spec-ctrl=no-xen` can be used to
@@ -1495,7 +1495,7 @@ pages) must also be specified via the tb
= <bool>
Applicability: x86
- Default: true
+ Default: false on parts vulnerable to TAA, true otherwise
Controls for the use of Transactional Synchronization eXtensions.
@@ -1505,6 +1505,19 @@ a control has been introduced which allo
On systems with the ability to turn TSX off, this boolean offers system wide
control of whether TSX is enabled or disabled.
+On parts vulnerable to CVE-2019-11135 / TSX Asynchronous Abort, the following
+logic applies:
+
+ * An explicit `tsx=` choice is honoured, even if it is `true` and would
+ result in a vulnerable system.
+
+ * When no explicit `tsx=` choice is given, parts vulnerable to TAA will be
+ mitigated by disabling TSX, as this is the lowest overhead option.
+
+ * If the use of TSX is important, the more expensive TAA mitigations can be
+ opted in to with `smt=0 spec-ctrl=md-clear`, at which point TSX will remain
+ active by default.
+
### ucode
> `= [<integer> | scan]`
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -130,6 +130,9 @@ static int __init parse_spec_ctrl(char *
if ( opt_pv_l1tf < 0 )
opt_pv_l1tf = 0;
+ if ( opt_tsx == -1 )
+ opt_tsx = -3;
+
disable_common:
opt_rsb_pv = 0;
opt_rsb_hvm = 0;
@@ -292,7 +295,7 @@ static void __init print_details(enum in
#endif
/* Settings for Xen's protection, irrespective of guests. */
- printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s, Other:%s%s%s\n",
+ printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s, Other:%s%s%s\n",
thunk == THUNK_NONE ? "N/A" :
thunk == THUNK_RETPOLINE ? "RETPOLINE" :
thunk == THUNK_LFENCE ? "LFENCE" :
@@ -301,6 +304,8 @@ static void __init print_details(enum in
(default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
!boot_cpu_has(X86_FEATURE_SSBD) ? "" :
(default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
+ !cpu_has_tsx_ctrl ? "" :
+ (opt_tsx & 1) ? " TSX+" : " TSX-",
opt_ibpb ? " IBPB" : "",
opt_l1d_flush ? " L1D_FLUSH" : "",
opt_md_clear_pv || opt_md_clear_hvm ? " VERW" : "");
@@ -772,6 +777,7 @@ void __init init_speculation_mitigations
{
enum ind_thunk thunk = THUNK_DEFAULT;
bool_t use_spec_ctrl = 0, ibrs = 0, hw_smt_enabled;
+ bool_t cpu_has_bug_taa = 0;
hw_smt_enabled = check_smt_enabled();
@@ -997,6 +1003,59 @@ void __init init_speculation_mitigations
"* See XSA-297. *\n"
"**************************************************************\n");
+ /*
+ * Vulnerability to TAA is a little complicated to quantify.
+ *
+ * In the pipeline, it is just another way to get speculative access to
+ * stale load port, store buffer or fill buffer data, and therefore can be
+ * considered a superset of MDS (on TSX-capable parts). On parts which
+ * predate MDS_NO, the existing VERW flushing will mitigate this
+ * sidechannel as well.
+ *
+ * On parts which contain MDS_NO, the lack of VERW flushing means that an
+ * attacker can still use TSX to target microarchitectural buffers to leak
+ * secrets. Therefore, we consider TAA to be the set of TSX-capable parts
+ * which have MDS_NO but lack TAA_NO.
+ *
+ * Note: cpu_has_rtm (== hle) could already be hidden by `tsx=0` on the
+ * cmdline. MSR_TSX_CTRL will only appear on TSX-capable parts, so
+ * we check both to spot TSX in a microcode/cmdline independent way.
+ */
+ if ( boot_cpu_has(X86_FEATURE_RTM) || cpu_has_tsx_ctrl )
+ {
+ uint64_t caps = 0;
+
+ if ( boot_cpu_data.cpuid_level >= 7 &&
+ (cpuid_count_edx(7, 0) & (1 << 29)) )
+ rdmsrl(MSR_ARCH_CAPABILITIES, caps);
+ cpu_has_bug_taa = (caps & ((1 << 5) | (1 << 8))) == (1 << 5);
+ }
+
+ /*
+ * On TAA-affected hardware, disabling TSX is the preferred mitigation, vs
+ * the MDS mitigation of disabling HT and using VERW flushing.
+ *
+ * On CPUs which advertise MDS_NO, VERW has no flushing side effect until
+ * the TSX_CTRL microcode is loaded, despite the MD_CLEAR CPUID bit being
+ * advertised, and there isn't a MD_CLEAR_2 flag to use...
+ *
+ * If we're on affected hardware, able to do something about it (which
+ * implies that VERW now works), no explicit TSX choice and traditional
+ * MDS mitigations (no-SMT, VERW) not obviosuly in use (someone might
+ * plausibly value TSX higher than Hyperthreading...), disable TSX to
+ * mitigate TAA.
+ */
+ if ( opt_tsx == -1 && cpu_has_bug_taa && cpu_has_tsx_ctrl &&
+ ((hw_smt_enabled && opt_smt) ||
+ !boot_cpu_has(X86_FEATURE_SC_VERW_IDLE)) )
+ {
+ setup_clear_cpu_cap(X86_FEATURE_HLE);
+ setup_clear_cpu_cap(X86_FEATURE_RTM);
+
+ opt_tsx = 0;
+ tsx_init();
+ }
+
print_details(thunk);
/*
--- a/xen/arch/x86/tsx.c
+++ b/xen/arch/x86/tsx.c
@@ -5,7 +5,8 @@
* Valid values:
* 1 => Explicit tsx=1
* 0 => Explicit tsx=0
- * -1 => Default, implicit tsx=1
+ * -1 => Default, implicit tsx=1, may change to 0 to mitigate TAA
+ * -3 => Implicit tsx=1 (feed-through from spec-ctrl=0)
*
* This is arranged such that the bottom bit encodes whether TSX is actually
* disabled, while identifying various explicit (>=0) and implicit (<0)
