1.. SPDX-License-Identifier: GPL-2.0 2 3TAA - TSX Asynchronous Abort 4====================================== 5 6TAA is a hardware vulnerability that allows unprivileged speculative access to 7data which is available in various CPU internal buffers by using asynchronous 8aborts within an Intel TSX transactional region. 9 10Affected processors 11------------------- 12 13This vulnerability only affects Intel processors that support Intel 14Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8) 15is 0 in the IA32_ARCH_CAPABILITIES MSR. On processors where the MDS_NO bit 16(bit 5) is 0 in the IA32_ARCH_CAPABILITIES MSR, the existing MDS mitigations 17also mitigate against TAA. 18 19Whether a processor is affected or not can be read out from the TAA 20vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`. 21 22Related CVEs 23------------ 24 25The following CVE entry is related to this TAA issue: 26 27 ============== ===== =================================================== 28 CVE-2019-11135 TAA TSX Asynchronous Abort (TAA) condition on some 29 microprocessors utilizing speculative execution may 30 allow an authenticated user to potentially enable 31 information disclosure via a side channel with 32 local access. 33 ============== ===== =================================================== 34 35Problem 36------- 37 38When performing store, load or L1 refill operations, processors write 39data into temporary microarchitectural structures (buffers). The data in 40those buffers can be forwarded to load operations as an optimization. 41 42Intel TSX is an extension to the x86 instruction set architecture that adds 43hardware transactional memory support to improve performance of multi-threaded 44software. TSX lets the processor expose and exploit concurrency hidden in an 45application due to dynamically avoiding unnecessary synchronization. 46 47TSX supports atomic memory transactions that are either committed (success) or 48aborted. During an abort, operations that happened within the transactional region 49are rolled back. An asynchronous abort takes place, among other options, when a 50different thread accesses a cache line that is also used within the transactional 51region when that access might lead to a data race. 52 53Immediately after an uncompleted asynchronous abort, certain speculatively 54executed loads may read data from those internal buffers and pass it to dependent 55operations. This can be then used to infer the value via a cache side channel 56attack. 57 58Because the buffers are potentially shared between Hyper-Threads cross 59Hyper-Thread attacks are possible. 60 61The victim of a malicious actor does not need to make use of TSX. Only the 62attacker needs to begin a TSX transaction and raise an asynchronous abort 63which in turn potenitally leaks data stored in the buffers. 64 65More detailed technical information is available in the TAA specific x86 66architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`. 67 68 69Attack scenarios 70---------------- 71 72Attacks against the TAA vulnerability can be implemented from unprivileged 73applications running on hosts or guests. 74 75As for MDS, the attacker has no control over the memory addresses that can 76be leaked. Only the victim is responsible for bringing data to the CPU. As 77a result, the malicious actor has to sample as much data as possible and 78then postprocess it to try to infer any useful information from it. 79 80A potential attacker only has read access to the data. Also, there is no direct 81privilege escalation by using this technique. 82 83 84.. _tsx_async_abort_sys_info: 85 86TAA system information 87----------------------- 88 89The Linux kernel provides a sysfs interface to enumerate the current TAA status 90of mitigated systems. The relevant sysfs file is: 91 92/sys/devices/system/cpu/vulnerabilities/tsx_async_abort 93 94The possible values in this file are: 95 96.. list-table:: 97 98 * - 'Vulnerable' 99 - The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied. 100 * - 'Vulnerable: Clear CPU buffers attempted, no microcode' 101 - The system tries to clear the buffers but the microcode might not support the operation. 102 * - 'Mitigation: Clear CPU buffers' 103 - The microcode has been updated to clear the buffers. TSX is still enabled. 104 * - 'Mitigation: TSX disabled' 105 - TSX is disabled. 106 * - 'Not affected' 107 - The CPU is not affected by this issue. 108 109.. _ucode_needed: 110 111Best effort mitigation mode 112^^^^^^^^^^^^^^^^^^^^^^^^^^^ 113 114If the processor is vulnerable, but the availability of the microcode-based 115mitigation mechanism is not advertised via CPUID the kernel selects a best 116effort mitigation mode. This mode invokes the mitigation instructions 117without a guarantee that they clear the CPU buffers. 118 119This is done to address virtualization scenarios where the host has the 120microcode update applied, but the hypervisor is not yet updated to expose the 121CPUID to the guest. If the host has updated microcode the protection takes 122effect; otherwise a few CPU cycles are wasted pointlessly. 123 124The state in the tsx_async_abort sysfs file reflects this situation 125accordingly. 126 127 128Mitigation mechanism 129-------------------- 130 131The kernel detects the affected CPUs and the presence of the microcode which is 132required. If a CPU is affected and the microcode is available, then the kernel 133enables the mitigation by default. 134 135 136The mitigation can be controlled at boot time via a kernel command line option. 137See :ref:`taa_mitigation_control_command_line`. 138 139.. _virt_mechanism: 140 141Virtualization mitigation 142^^^^^^^^^^^^^^^^^^^^^^^^^ 143 144Affected systems where the host has TAA microcode and TAA is mitigated by 145having disabled TSX previously, are not vulnerable regardless of the status 146of the VMs. 147 148In all other cases, if the host either does not have the TAA microcode or 149the kernel is not mitigated, the system might be vulnerable. 150 151 152.. _taa_mitigation_control_command_line: 153 154Mitigation control on the kernel command line 155--------------------------------------------- 156 157The kernel command line allows to control the TAA mitigations at boot time with 158the option "tsx_async_abort=". The valid arguments for this option are: 159 160 ============ ============================================================= 161 off This option disables the TAA mitigation on affected platforms. 162 If the system has TSX enabled (see next parameter) and the CPU 163 is affected, the system is vulnerable. 164 165 full TAA mitigation is enabled. If TSX is enabled, on an affected 166 system it will clear CPU buffers on ring transitions. On 167 systems which are MDS-affected and deploy MDS mitigation, 168 TAA is also mitigated. Specifying this option on those 169 systems will have no effect. 170 171 full,nosmt The same as tsx_async_abort=full, with SMT disabled on 172 vulnerable CPUs that have TSX enabled. This is the complete 173 mitigation. When TSX is disabled, SMT is not disabled because 174 CPU is not vulnerable to cross-thread TAA attacks. 175 ============ ============================================================= 176 177Not specifying this option is equivalent to "tsx_async_abort=full". For 178processors that are affected by both TAA and MDS, specifying just 179"tsx_async_abort=off" without an accompanying "mds=off" will have no 180effect as the same mitigation is used for both vulnerabilities. 181 182The kernel command line also allows to control the TSX feature using the 183parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used 184to control the TSX feature and the enumeration of the TSX feature bits (RTM 185and HLE) in CPUID. 186 187The valid options are: 188 189 ============ ============================================================= 190 off Disables TSX on the system. 191 192 Note that this option takes effect only on newer CPUs which are 193 not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1 194 and which get the new IA32_TSX_CTRL MSR through a microcode 195 update. This new MSR allows for the reliable deactivation of 196 the TSX functionality. 197 198 on Enables TSX. 199 200 Although there are mitigations for all known security 201 vulnerabilities, TSX has been known to be an accelerator for 202 several previous speculation-related CVEs, and so there may be 203 unknown security risks associated with leaving it enabled. 204 205 auto Disables TSX if X86_BUG_TAA is present, otherwise enables TSX 206 on the system. 207 ============ ============================================================= 208 209Not specifying this option is equivalent to "tsx=off". 210 211The following combinations of the "tsx_async_abort" and "tsx" are possible. For 212affected platforms tsx=auto is equivalent to tsx=off and the result will be: 213 214 ========= ========================== ========================================= 215 tsx=on tsx_async_abort=full The system will use VERW to clear CPU 216 buffers. Cross-thread attacks are still 217 possible on SMT machines. 218 tsx=on tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT 219 mitigated. 220 tsx=on tsx_async_abort=off The system is vulnerable. 221 tsx=off tsx_async_abort=full TSX might be disabled if microcode 222 provides a TSX control MSR. If so, 223 system is not vulnerable. 224 tsx=off tsx_async_abort=full,nosmt Ditto 225 tsx=off tsx_async_abort=off ditto 226 ========= ========================== ========================================= 227 228 229For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU 230buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0) 231"tsx" command line argument has no effect. 232 233For the affected platforms below table indicates the mitigation status for the 234combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO 235and TSX_CTRL_MSR. 236 237 ======= ========= ============= ======================================== 238 MDS_NO MD_CLEAR TSX_CTRL_MSR Status 239 ======= ========= ============= ======================================== 240 0 0 0 Vulnerable (needs microcode) 241 0 1 0 MDS and TAA mitigated via VERW 242 1 1 0 MDS fixed, TAA vulnerable if TSX enabled 243 because MD_CLEAR has no meaning and 244 VERW is not guaranteed to clear buffers 245 1 X 1 MDS fixed, TAA can be mitigated by 246 VERW or TSX_CTRL_MSR 247 ======= ========= ============= ======================================== 248 249Mitigation selection guide 250-------------------------- 251 2521. Trusted userspace and guests 253^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 254 255If all user space applications are from a trusted source and do not execute 256untrusted code which is supplied externally, then the mitigation can be 257disabled. The same applies to virtualized environments with trusted guests. 258 259 2602. Untrusted userspace and guests 261^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 262 263If there are untrusted applications or guests on the system, enabling TSX 264might allow a malicious actor to leak data from the host or from other 265processes running on the same physical core. 266 267If the microcode is available and the TSX is disabled on the host, attacks 268are prevented in a virtualized environment as well, even if the VMs do not 269explicitly enable the mitigation. 270 271 272.. _taa_default_mitigations: 273 274Default mitigations 275------------------- 276 277The kernel's default action for vulnerable processors is: 278 279 - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off). 280