0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 TAA - TSX Asynchronous Abort
0004 ======================================
0005
0006 TAA is a hardware vulnerability that allows unprivileged speculative access to
0007 data which is available in various CPU internal buffers by using asynchronous
0008 aborts within an Intel TSX transactional region.
0009
0010 Affected processors
0011 -------------------
0012
0013 This vulnerability only affects Intel processors that support Intel
0014 Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8)
0015 is 0 in the IA32_ARCH_CAPABILITIES MSR. On processors where the MDS_NO bit
0016 (bit 5) is 0 in the IA32_ARCH_CAPABILITIES MSR, the existing MDS mitigations
0017 also mitigate against TAA.
0018
0019 Whether a processor is affected or not can be read out from the TAA
0020 vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`.
0021
0022 Related CVEs
0023 ------------
0024
0025 The following CVE entry is related to this TAA issue:
0026
0027 ============== ===== ===================================================
0028 CVE-2019-11135 TAA TSX Asynchronous Abort (TAA) condition on some
0029 microprocessors utilizing speculative execution may
0030 allow an authenticated user to potentially enable
0031 information disclosure via a side channel with
0032 local access.
0033 ============== ===== ===================================================
0034
0035 Problem
0036 -------
0037
0038 When performing store, load or L1 refill operations, processors write
0039 data into temporary microarchitectural structures (buffers). The data in
0040 those buffers can be forwarded to load operations as an optimization.
0041
0042 Intel TSX is an extension to the x86 instruction set architecture that adds
0043 hardware transactional memory support to improve performance of multi-threaded
0044 software. TSX lets the processor expose and exploit concurrency hidden in an
0045 application due to dynamically avoiding unnecessary synchronization.
0046
0047 TSX supports atomic memory transactions that are either committed (success) or
0048 aborted. During an abort, operations that happened within the transactional region
0049 are rolled back. An asynchronous abort takes place, among other options, when a
0050 different thread accesses a cache line that is also used within the transactional
0051 region when that access might lead to a data race.
0052
0053 Immediately after an uncompleted asynchronous abort, certain speculatively
0054 executed loads may read data from those internal buffers and pass it to dependent
0055 operations. This can be then used to infer the value via a cache side channel
0056 attack.
0057
0058 Because the buffers are potentially shared between Hyper-Threads cross
0059 Hyper-Thread attacks are possible.
0060
0061 The victim of a malicious actor does not need to make use of TSX. Only the
0062 attacker needs to begin a TSX transaction and raise an asynchronous abort
0063 which in turn potentially leaks data stored in the buffers.
0064
0065 More detailed technical information is available in the TAA specific x86
0066 architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
0067
0068
0069 Attack scenarios
0070 ----------------
0071
0072 Attacks against the TAA vulnerability can be implemented from unprivileged
0073 applications running on hosts or guests.
0074
0075 As for MDS, the attacker has no control over the memory addresses that can
0076 be leaked. Only the victim is responsible for bringing data to the CPU. As
0077 a result, the malicious actor has to sample as much data as possible and
0078 then postprocess it to try to infer any useful information from it.
0079
0080 A potential attacker only has read access to the data. Also, there is no direct
0081 privilege escalation by using this technique.
0082
0083
0084 .. _tsx_async_abort_sys_info:
0085
0086 TAA system information
0087 -----------------------
0088
0089 The Linux kernel provides a sysfs interface to enumerate the current TAA status
0090 of mitigated systems. The relevant sysfs file is:
0091
0092 /sys/devices/system/cpu/vulnerabilities/tsx_async_abort
0093
0094 The possible values in this file are:
0095
0096 .. list-table::
0097
0098 * - 'Vulnerable'
0099 - The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.
0100 * - 'Vulnerable: Clear CPU buffers attempted, no microcode'
0101 - The system tries to clear the buffers but the microcode might not support the operation.
0102 * - 'Mitigation: Clear CPU buffers'
0103 - The microcode has been updated to clear the buffers. TSX is still enabled.
0104 * - 'Mitigation: TSX disabled'
0105 - TSX is disabled.
0106 * - 'Not affected'
0107 - The CPU is not affected by this issue.
0108
0109 .. _ucode_needed:
0110
0111 Best effort mitigation mode
0112 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
0113
0114 If the processor is vulnerable, but the availability of the microcode-based
0115 mitigation mechanism is not advertised via CPUID the kernel selects a best
0116 effort mitigation mode. This mode invokes the mitigation instructions
0117 without a guarantee that they clear the CPU buffers.
0118
0119 This is done to address virtualization scenarios where the host has the
0120 microcode update applied, but the hypervisor is not yet updated to expose the
0121 CPUID to the guest. If the host has updated microcode the protection takes
0122 effect; otherwise a few CPU cycles are wasted pointlessly.
0123
0124 The state in the tsx_async_abort sysfs file reflects this situation
0125 accordingly.
0126
0127
0128 Mitigation mechanism
0129 --------------------
0130
0131 The kernel detects the affected CPUs and the presence of the microcode which is
0132 required. If a CPU is affected and the microcode is available, then the kernel
0133 enables the mitigation by default.
0134
0135
0136 The mitigation can be controlled at boot time via a kernel command line option.
0137 See :ref:`taa_mitigation_control_command_line`.
0138
0139 Virtualization mitigation
0140 ^^^^^^^^^^^^^^^^^^^^^^^^^
0141
0142 Affected systems where the host has TAA microcode and TAA is mitigated by
0143 having disabled TSX previously, are not vulnerable regardless of the status
0144 of the VMs.
0145
0146 In all other cases, if the host either does not have the TAA microcode or
0147 the kernel is not mitigated, the system might be vulnerable.
0148
0149
0150 .. _taa_mitigation_control_command_line:
0151
0152 Mitigation control on the kernel command line
0153 ---------------------------------------------
0154
0155 The kernel command line allows to control the TAA mitigations at boot time with
0156 the option "tsx_async_abort=". The valid arguments for this option are:
0157
0158 ============ =============================================================
0159 off This option disables the TAA mitigation on affected platforms.
0160 If the system has TSX enabled (see next parameter) and the CPU
0161 is affected, the system is vulnerable.
0162
0163 full TAA mitigation is enabled. If TSX is enabled, on an affected
0164 system it will clear CPU buffers on ring transitions. On
0165 systems which are MDS-affected and deploy MDS mitigation,
0166 TAA is also mitigated. Specifying this option on those
0167 systems will have no effect.
0168
0169 full,nosmt The same as tsx_async_abort=full, with SMT disabled on
0170 vulnerable CPUs that have TSX enabled. This is the complete
0171 mitigation. When TSX is disabled, SMT is not disabled because
0172 CPU is not vulnerable to cross-thread TAA attacks.
0173 ============ =============================================================
0174
0175 Not specifying this option is equivalent to "tsx_async_abort=full". For
0176 processors that are affected by both TAA and MDS, specifying just
0177 "tsx_async_abort=off" without an accompanying "mds=off" will have no
0178 effect as the same mitigation is used for both vulnerabilities.
0179
0180 The kernel command line also allows to control the TSX feature using the
0181 parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
0182 to control the TSX feature and the enumeration of the TSX feature bits (RTM
0183 and HLE) in CPUID.
0184
0185 The valid options are:
0186
0187 ============ =============================================================
0188 off Disables TSX on the system.
0189
0190 Note that this option takes effect only on newer CPUs which are
0191 not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1
0192 and which get the new IA32_TSX_CTRL MSR through a microcode
0193 update. This new MSR allows for the reliable deactivation of
0194 the TSX functionality.
0195
0196 on Enables TSX.
0197
0198 Although there are mitigations for all known security
0199 vulnerabilities, TSX has been known to be an accelerator for
0200 several previous speculation-related CVEs, and so there may be
0201 unknown security risks associated with leaving it enabled.
0202
0203 auto Disables TSX if X86_BUG_TAA is present, otherwise enables TSX
0204 on the system.
0205 ============ =============================================================
0206
0207 Not specifying this option is equivalent to "tsx=off".
0208
0209 The following combinations of the "tsx_async_abort" and "tsx" are possible. For
0210 affected platforms tsx=auto is equivalent to tsx=off and the result will be:
0211
0212 ========= ========================== =========================================
0213 tsx=on tsx_async_abort=full The system will use VERW to clear CPU
0214 buffers. Cross-thread attacks are still
0215 possible on SMT machines.
0216 tsx=on tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT
0217 mitigated.
0218 tsx=on tsx_async_abort=off The system is vulnerable.
0219 tsx=off tsx_async_abort=full TSX might be disabled if microcode
0220 provides a TSX control MSR. If so,
0221 system is not vulnerable.
0222 tsx=off tsx_async_abort=full,nosmt Ditto
0223 tsx=off tsx_async_abort=off ditto
0224 ========= ========================== =========================================
0225
0226
0227 For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
0228 buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)
0229 "tsx" command line argument has no effect.
0230
0231 For the affected platforms below table indicates the mitigation status for the
0232 combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
0233 and TSX_CTRL_MSR.
0234
0235 ======= ========= ============= ========================================
0236 MDS_NO MD_CLEAR TSX_CTRL_MSR Status
0237 ======= ========= ============= ========================================
0238 0 0 0 Vulnerable (needs microcode)
0239 0 1 0 MDS and TAA mitigated via VERW
0240 1 1 0 MDS fixed, TAA vulnerable if TSX enabled
0241 because MD_CLEAR has no meaning and
0242 VERW is not guaranteed to clear buffers
0243 1 X 1 MDS fixed, TAA can be mitigated by
0244 VERW or TSX_CTRL_MSR
0245 ======= ========= ============= ========================================
0246
0247 Mitigation selection guide
0248 --------------------------
0249
0250 1. Trusted userspace and guests
0251 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0252
0253 If all user space applications are from a trusted source and do not execute
0254 untrusted code which is supplied externally, then the mitigation can be
0255 disabled. The same applies to virtualized environments with trusted guests.
0256
0257
0258 2. Untrusted userspace and guests
0259 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0260
0261 If there are untrusted applications or guests on the system, enabling TSX
0262 might allow a malicious actor to leak data from the host or from other
0263 processes running on the same physical core.
0264
0265 If the microcode is available and the TSX is disabled on the host, attacks
0266 are prevented in a virtualized environment as well, even if the VMs do not
0267 explicitly enable the mitigation.
0268
0269
0270 .. _taa_default_mitigations:
0271
0272 Default mitigations
0273 -------------------
0274
0275 The kernel's default action for vulnerable processors is:
0276
0277 - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).
