Pawan Gupta | ba54aad | 2019-10-23 12:32:55 +0200 | [diff] [blame] | 1 | .. SPDX-License-Identifier: GPL-2.0 |
| 2 | |
| 3 | TAA - TSX Asynchronous Abort |
| 4 | ====================================== |
| 5 | |
| 6 | TAA is a hardware vulnerability that allows unprivileged speculative access to |
| 7 | data which is available in various CPU internal buffers by using asynchronous |
| 8 | aborts within an Intel TSX transactional region. |
| 9 | |
| 10 | Affected processors |
| 11 | ------------------- |
| 12 | |
| 13 | This vulnerability only affects Intel processors that support Intel |
| 14 | Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8) |
| 15 | is 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 |
| 17 | also mitigate against TAA. |
| 18 | |
| 19 | Whether a processor is affected or not can be read out from the TAA |
| 20 | vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`. |
| 21 | |
| 22 | Related CVEs |
| 23 | ------------ |
| 24 | |
| 25 | The 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 | |
| 35 | Problem |
| 36 | ------- |
| 37 | |
| 38 | When performing store, load or L1 refill operations, processors write |
| 39 | data into temporary microarchitectural structures (buffers). The data in |
| 40 | those buffers can be forwarded to load operations as an optimization. |
| 41 | |
| 42 | Intel TSX is an extension to the x86 instruction set architecture that adds |
| 43 | hardware transactional memory support to improve performance of multi-threaded |
| 44 | software. TSX lets the processor expose and exploit concurrency hidden in an |
| 45 | application due to dynamically avoiding unnecessary synchronization. |
| 46 | |
| 47 | TSX supports atomic memory transactions that are either committed (success) or |
| 48 | aborted. During an abort, operations that happened within the transactional region |
| 49 | are rolled back. An asynchronous abort takes place, among other options, when a |
| 50 | different thread accesses a cache line that is also used within the transactional |
| 51 | region when that access might lead to a data race. |
| 52 | |
| 53 | Immediately after an uncompleted asynchronous abort, certain speculatively |
| 54 | executed loads may read data from those internal buffers and pass it to dependent |
| 55 | operations. This can be then used to infer the value via a cache side channel |
| 56 | attack. |
| 57 | |
| 58 | Because the buffers are potentially shared between Hyper-Threads cross |
| 59 | Hyper-Thread attacks are possible. |
| 60 | |
| 61 | The victim of a malicious actor does not need to make use of TSX. Only the |
| 62 | attacker needs to begin a TSX transaction and raise an asynchronous abort |
| 63 | which in turn potenitally leaks data stored in the buffers. |
| 64 | |
| 65 | More detailed technical information is available in the TAA specific x86 |
| 66 | architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`. |
| 67 | |
| 68 | |
| 69 | Attack scenarios |
| 70 | ---------------- |
| 71 | |
| 72 | Attacks against the TAA vulnerability can be implemented from unprivileged |
| 73 | applications running on hosts or guests. |
| 74 | |
| 75 | As for MDS, the attacker has no control over the memory addresses that can |
| 76 | be leaked. Only the victim is responsible for bringing data to the CPU. As |
| 77 | a result, the malicious actor has to sample as much data as possible and |
| 78 | then postprocess it to try to infer any useful information from it. |
| 79 | |
| 80 | A potential attacker only has read access to the data. Also, there is no direct |
| 81 | privilege escalation by using this technique. |
| 82 | |
| 83 | |
| 84 | .. _tsx_async_abort_sys_info: |
| 85 | |
| 86 | TAA system information |
| 87 | ----------------------- |
| 88 | |
| 89 | The Linux kernel provides a sysfs interface to enumerate the current TAA status |
| 90 | of mitigated systems. The relevant sysfs file is: |
| 91 | |
| 92 | /sys/devices/system/cpu/vulnerabilities/tsx_async_abort |
| 93 | |
| 94 | The 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 | |
| 111 | Best effort mitigation mode |
| 112 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 113 | |
| 114 | If the processor is vulnerable, but the availability of the microcode-based |
| 115 | mitigation mechanism is not advertised via CPUID the kernel selects a best |
| 116 | effort mitigation mode. This mode invokes the mitigation instructions |
| 117 | without a guarantee that they clear the CPU buffers. |
| 118 | |
| 119 | This is done to address virtualization scenarios where the host has the |
| 120 | microcode update applied, but the hypervisor is not yet updated to expose the |
| 121 | CPUID to the guest. If the host has updated microcode the protection takes |
| 122 | effect; otherwise a few CPU cycles are wasted pointlessly. |
| 123 | |
| 124 | The state in the tsx_async_abort sysfs file reflects this situation |
| 125 | accordingly. |
| 126 | |
| 127 | |
| 128 | Mitigation mechanism |
| 129 | -------------------- |
| 130 | |
| 131 | The kernel detects the affected CPUs and the presence of the microcode which is |
| 132 | required. If a CPU is affected and the microcode is available, then the kernel |
| 133 | enables the mitigation by default. |
| 134 | |
| 135 | |
| 136 | The mitigation can be controlled at boot time via a kernel command line option. |
| 137 | See :ref:`taa_mitigation_control_command_line`. |
| 138 | |
| 139 | .. _virt_mechanism: |
| 140 | |
| 141 | Virtualization mitigation |
| 142 | ^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 143 | |
| 144 | Affected systems where the host has TAA microcode and TAA is mitigated by |
| 145 | having disabled TSX previously, are not vulnerable regardless of the status |
| 146 | of the VMs. |
| 147 | |
| 148 | In all other cases, if the host either does not have the TAA microcode or |
| 149 | the kernel is not mitigated, the system might be vulnerable. |
| 150 | |
| 151 | |
| 152 | .. _taa_mitigation_control_command_line: |
| 153 | |
| 154 | Mitigation control on the kernel command line |
| 155 | --------------------------------------------- |
| 156 | |
| 157 | The kernel command line allows to control the TAA mitigations at boot time with |
| 158 | the 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 | |
Waiman Long | 5aba0ad | 2019-11-15 11:14:44 -0500 | [diff] [blame] | 177 | Not specifying this option is equivalent to "tsx_async_abort=full". For |
| 178 | processors that are affected by both TAA and MDS, specifying just |
| 179 | "tsx_async_abort=off" without an accompanying "mds=off" will have no |
| 180 | effect as the same mitigation is used for both vulnerabilities. |
Pawan Gupta | ba54aad | 2019-10-23 12:32:55 +0200 | [diff] [blame] | 181 | |
| 182 | The kernel command line also allows to control the TSX feature using the |
| 183 | parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used |
| 184 | to control the TSX feature and the enumeration of the TSX feature bits (RTM |
| 185 | and HLE) in CPUID. |
| 186 | |
| 187 | The 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 | |
| 209 | Not specifying this option is equivalent to "tsx=off". |
| 210 | |
| 211 | The following combinations of the "tsx_async_abort" and "tsx" are possible. For |
| 212 | affected 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 | |
| 229 | For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU |
| 230 | buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0) |
| 231 | "tsx" command line argument has no effect. |
| 232 | |
| 233 | For the affected platforms below table indicates the mitigation status for the |
| 234 | combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO |
| 235 | and 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 | |
| 249 | Mitigation selection guide |
| 250 | -------------------------- |
| 251 | |
| 252 | 1. Trusted userspace and guests |
| 253 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 254 | |
| 255 | If all user space applications are from a trusted source and do not execute |
| 256 | untrusted code which is supplied externally, then the mitigation can be |
| 257 | disabled. The same applies to virtualized environments with trusted guests. |
| 258 | |
| 259 | |
| 260 | 2. Untrusted userspace and guests |
| 261 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 262 | |
| 263 | If there are untrusted applications or guests on the system, enabling TSX |
| 264 | might allow a malicious actor to leak data from the host or from other |
| 265 | processes running on the same physical core. |
| 266 | |
| 267 | If the microcode is available and the TSX is disabled on the host, attacks |
| 268 | are prevented in a virtualized environment as well, even if the VMs do not |
| 269 | explicitly enable the mitigation. |
| 270 | |
| 271 | |
| 272 | .. _taa_default_mitigations: |
| 273 | |
| 274 | Default mitigations |
| 275 | ------------------- |
| 276 | |
| 277 | The kernel's default action for vulnerable processors is: |
| 278 | |
| 279 | - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off). |