Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
SUSE:SLE-12-SP3:Update
xen.14030
xsa305-2.patch
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
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)
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor