271 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3TAA - TSX Asynchronous Abort4======================================5 6TAA is a hardware vulnerability that allows unprivileged speculative access to7data which is available in various CPU internal buffers by using asynchronous8aborts within an Intel TSX transactional region.9 10Affected processors11-------------------12 13This vulnerability only affects Intel processors that support Intel14Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8)15is 0 in the IA32_ARCH_CAPABILITIES MSR. On processors where the MDS_NO bit16(bit 5) is 0 in the IA32_ARCH_CAPABILITIES MSR, the existing MDS mitigations17also mitigate against TAA.18 19Whether a processor is affected or not can be read out from the TAA20vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`.21 22Related CVEs23------------24 25The following CVE entry is related to this TAA issue:26 27 ============== ===== ===================================================28 CVE-2019-11135 TAA TSX Asynchronous Abort (TAA) condition on some29 microprocessors utilizing speculative execution may30 allow an authenticated user to potentially enable31 information disclosure via a side channel with32 local access.33 ============== ===== ===================================================34 35Problem36-------37 38When performing store, load or L1 refill operations, processors write39data into temporary microarchitectural structures (buffers). The data in40those buffers can be forwarded to load operations as an optimization.41 42Intel TSX is an extension to the x86 instruction set architecture that adds43hardware transactional memory support to improve performance of multi-threaded44software. TSX lets the processor expose and exploit concurrency hidden in an45application due to dynamically avoiding unnecessary synchronization.46 47TSX supports atomic memory transactions that are either committed (success) or48aborted. During an abort, operations that happened within the transactional region49are rolled back. An asynchronous abort takes place, among other options, when a50different thread accesses a cache line that is also used within the transactional51region when that access might lead to a data race.52 53Immediately after an uncompleted asynchronous abort, certain speculatively54executed loads may read data from those internal buffers and pass it to dependent55operations. This can be then used to infer the value via a cache side channel56attack.57 58Because the buffers are potentially shared between Hyper-Threads cross59Hyper-Thread attacks are possible.60 61The victim of a malicious actor does not need to make use of TSX. Only the62attacker needs to begin a TSX transaction and raise an asynchronous abort63which in turn potentially leaks data stored in the buffers.64 65More detailed technical information is available in the TAA specific x8666architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`.67 68 69Attack scenarios70----------------71 72Attacks against the TAA vulnerability can be implemented from unprivileged73applications running on hosts or guests.74 75As for MDS, the attacker has no control over the memory addresses that can76be leaked. Only the victim is responsible for bringing data to the CPU. As77a result, the malicious actor has to sample as much data as possible and78then 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 direct81privilege escalation by using this technique.82 83 84.. _tsx_async_abort_sys_info:85 86TAA system information87-----------------------88 89The Linux kernel provides a sysfs interface to enumerate the current TAA status90of mitigated systems. The relevant sysfs file is:91 92/sys/devices/system/cpu/vulnerabilities/tsx_async_abort93 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 processor is vulnerable but microcode is not updated. The102 mitigation is enabled on a best effort basis.103 104 If the processor is vulnerable but the availability of the microcode105 based mitigation mechanism is not advertised via CPUID, the kernel106 selects a best effort mitigation mode. This mode invokes the mitigation107 instructions without a guarantee that they clear the CPU buffers.108 109 This is done to address virtualization scenarios where the host has the110 microcode update applied, but the hypervisor is not yet updated to111 expose the CPUID to the guest. If the host has updated microcode the112 protection takes effect; otherwise a few CPU cycles are wasted113 pointlessly.114 * - 'Mitigation: Clear CPU buffers'115 - The microcode has been updated to clear the buffers. TSX is still enabled.116 * - 'Mitigation: TSX disabled'117 - TSX is disabled.118 * - 'Not affected'119 - The CPU is not affected by this issue.120 121Mitigation mechanism122--------------------123 124The kernel detects the affected CPUs and the presence of the microcode which is125required. If a CPU is affected and the microcode is available, then the kernel126enables the mitigation by default.127 128 129The mitigation can be controlled at boot time via a kernel command line option.130See :ref:`taa_mitigation_control_command_line`.131 132Virtualization mitigation133^^^^^^^^^^^^^^^^^^^^^^^^^134 135Affected systems where the host has TAA microcode and TAA is mitigated by136having disabled TSX previously, are not vulnerable regardless of the status137of the VMs.138 139In all other cases, if the host either does not have the TAA microcode or140the kernel is not mitigated, the system might be vulnerable.141 142 143.. _taa_mitigation_control_command_line:144 145Mitigation control on the kernel command line146---------------------------------------------147 148The kernel command line allows to control the TAA mitigations at boot time with149the option "tsx_async_abort=". The valid arguments for this option are:150 151 ============ =============================================================152 off This option disables the TAA mitigation on affected platforms.153 If the system has TSX enabled (see next parameter) and the CPU154 is affected, the system is vulnerable.155 156 full TAA mitigation is enabled. If TSX is enabled, on an affected157 system it will clear CPU buffers on ring transitions. On158 systems which are MDS-affected and deploy MDS mitigation,159 TAA is also mitigated. Specifying this option on those160 systems will have no effect.161 162 full,nosmt The same as tsx_async_abort=full, with SMT disabled on163 vulnerable CPUs that have TSX enabled. This is the complete164 mitigation. When TSX is disabled, SMT is not disabled because165 CPU is not vulnerable to cross-thread TAA attacks.166 ============ =============================================================167 168Not specifying this option is equivalent to "tsx_async_abort=full". For169processors that are affected by both TAA and MDS, specifying just170"tsx_async_abort=off" without an accompanying "mds=off" will have no171effect as the same mitigation is used for both vulnerabilities.172 173The kernel command line also allows to control the TSX feature using the174parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used175to control the TSX feature and the enumeration of the TSX feature bits (RTM176and HLE) in CPUID.177 178The valid options are:179 180 ============ =============================================================181 off Disables TSX on the system.182 183 Note that this option takes effect only on newer CPUs which are184 not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1185 and which get the new IA32_TSX_CTRL MSR through a microcode186 update. This new MSR allows for the reliable deactivation of187 the TSX functionality.188 189 on Enables TSX.190 191 Although there are mitigations for all known security192 vulnerabilities, TSX has been known to be an accelerator for193 several previous speculation-related CVEs, and so there may be194 unknown security risks associated with leaving it enabled.195 196 auto Disables TSX if X86_BUG_TAA is present, otherwise enables TSX197 on the system.198 ============ =============================================================199 200Not specifying this option is equivalent to "tsx=off".201 202The following combinations of the "tsx_async_abort" and "tsx" are possible. For203affected platforms tsx=auto is equivalent to tsx=off and the result will be:204 205 ========= ========================== =========================================206 tsx=on tsx_async_abort=full The system will use VERW to clear CPU207 buffers. Cross-thread attacks are still208 possible on SMT machines.209 tsx=on tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT210 mitigated.211 tsx=on tsx_async_abort=off The system is vulnerable.212 tsx=off tsx_async_abort=full TSX might be disabled if microcode213 provides a TSX control MSR. If so,214 system is not vulnerable.215 tsx=off tsx_async_abort=full,nosmt Ditto216 tsx=off tsx_async_abort=off ditto217 ========= ========================== =========================================218 219 220For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU221buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)222"tsx" command line argument has no effect.223 224For the affected platforms below table indicates the mitigation status for the225combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO226and TSX_CTRL_MSR.227 228 ======= ========= ============= ========================================229 MDS_NO MD_CLEAR TSX_CTRL_MSR Status230 ======= ========= ============= ========================================231 0 0 0 Vulnerable (needs microcode)232 0 1 0 MDS and TAA mitigated via VERW233 1 1 0 MDS fixed, TAA vulnerable if TSX enabled234 because MD_CLEAR has no meaning and235 VERW is not guaranteed to clear buffers236 1 X 1 MDS fixed, TAA can be mitigated by237 VERW or TSX_CTRL_MSR238 ======= ========= ============= ========================================239 240Mitigation selection guide241--------------------------242 2431. Trusted userspace and guests244^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^245 246If all user space applications are from a trusted source and do not execute247untrusted code which is supplied externally, then the mitigation can be248disabled. The same applies to virtualized environments with trusted guests.249 250 2512. Untrusted userspace and guests252^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^253 254If there are untrusted applications or guests on the system, enabling TSX255might allow a malicious actor to leak data from the host or from other256processes running on the same physical core.257 258If the microcode is available and the TSX is disabled on the host, attacks259are prevented in a virtualized environment as well, even if the VMs do not260explicitly enable the mitigation.261 262 263.. _taa_default_mitigations:264 265Default mitigations266-------------------267 268The kernel's default action for vulnerable processors is:269 270 - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).271