xref: /linux/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst (revision 0ea5c948cb64bab5bc7a5516774eb8536f05aa0d)
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 potentially leaks data stored in the buffers.
64
65More detailed technical information is available in the TAA specific x86
66architecture section: :ref:`Documentation/arch/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 processor is vulnerable but microcode is not updated. The
102       mitigation is enabled on a best effort basis.
103
104       If the processor is vulnerable but the availability of the microcode
105       based mitigation mechanism is not advertised via CPUID, the kernel
106       selects a best effort mitigation mode. This mode invokes the mitigation
107       instructions without a guarantee that they clear the CPU buffers.
108
109       This is done to address virtualization scenarios where the host has the
110       microcode update applied, but the hypervisor is not yet updated to
111       expose the CPUID to the guest. If the host has updated microcode the
112       protection takes effect; otherwise a few CPU cycles are wasted
113       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 mechanism
122--------------------
123
124The kernel detects the affected CPUs and the presence of the microcode which is
125required. If a CPU is affected and the microcode is available, then the kernel
126enables 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 mitigation
133^^^^^^^^^^^^^^^^^^^^^^^^^
134
135Affected systems where the host has TAA microcode and TAA is mitigated by
136having disabled TSX previously, are not vulnerable regardless of the status
137of the VMs.
138
139In all other cases, if the host either does not have the TAA microcode or
140the kernel is not mitigated, the system might be vulnerable.
141
142
143.. _taa_mitigation_control_command_line:
144
145Mitigation control on the kernel command line
146---------------------------------------------
147
148The kernel command line allows to control the TAA mitigations at boot time with
149the 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 CPU
154                is affected, the system is vulnerable.
155
156  full	        TAA mitigation is enabled. If TSX is enabled, on an affected
157                system it will clear CPU buffers on ring transitions. On
158                systems which are MDS-affected and deploy MDS mitigation,
159                TAA is also mitigated. Specifying this option on those
160                systems will have no effect.
161
162  full,nosmt    The same as tsx_async_abort=full, with SMT disabled on
163                vulnerable CPUs that have TSX enabled. This is the complete
164                mitigation. When TSX is disabled, SMT is not disabled because
165                CPU is not vulnerable to cross-thread TAA attacks.
166  ============  =============================================================
167
168Not specifying this option is equivalent to "tsx_async_abort=full". For
169processors that are affected by both TAA and MDS, specifying just
170"tsx_async_abort=off" without an accompanying "mds=off" will have no
171effect as the same mitigation is used for both vulnerabilities.
172
173The kernel command line also allows to control the TSX feature using the
174parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
175to control the TSX feature and the enumeration of the TSX feature bits (RTM
176and 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 are
184                not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1
185                and which get the new IA32_TSX_CTRL MSR through a microcode
186                update. This new MSR allows for the reliable deactivation of
187                the TSX functionality.
188
189  on		Enables TSX.
190
191                Although there are mitigations for all known security
192                vulnerabilities, TSX has been known to be an accelerator for
193                several previous speculation-related CVEs, and so there may be
194                unknown security risks associated with leaving it enabled.
195
196  auto		Disables TSX if X86_BUG_TAA is present, otherwise enables TSX
197                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. For
203affected 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 CPU
207                                          buffers. Cross-thread attacks are still
208					  possible on SMT machines.
209  tsx=on     tsx_async_abort=full,nosmt   As above, cross-thread attacks on SMT
210                                          mitigated.
211  tsx=on     tsx_async_abort=off          The system is vulnerable.
212  tsx=off    tsx_async_abort=full         TSX might be disabled if microcode
213                                          provides a TSX control MSR. If so,
214					  system is not vulnerable.
215  tsx=off    tsx_async_abort=full,nosmt   Ditto
216  tsx=off    tsx_async_abort=off          ditto
217  =========  ==========================   =========================================
218
219
220For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
221buffers.  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 the
225combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
226and TSX_CTRL_MSR.
227
228  =======  =========  =============  ========================================
229  MDS_NO   MD_CLEAR   TSX_CTRL_MSR   Status
230  =======  =========  =============  ========================================
231    0          0            0        Vulnerable (needs microcode)
232    0          1            0        MDS and TAA mitigated via VERW
233    1          1            0        MDS fixed, TAA vulnerable if TSX enabled
234                                     because MD_CLEAR has no meaning and
235                                     VERW is not guaranteed to clear buffers
236    1          X            1        MDS fixed, TAA can be mitigated by
237                                     VERW or TSX_CTRL_MSR
238  =======  =========  =============  ========================================
239
240Mitigation selection guide
241--------------------------
242
2431. Trusted userspace and guests
244^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
245
246If all user space applications are from a trusted source and do not execute
247untrusted code which is supplied externally, then the mitigation can be
248disabled. The same applies to virtualized environments with trusted guests.
249
250
2512. Untrusted userspace and guests
252^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
253
254If there are untrusted applications or guests on the system, enabling TSX
255might allow a malicious actor to leak data from the host or from other
256processes running on the same physical core.
257
258If the microcode is available and the TSX is disabled on the host, attacks
259are prevented in a virtualized environment as well, even if the VMs do not
260explicitly enable the mitigation.
261
262
263.. _taa_default_mitigations:
264
265Default mitigations
266-------------------
267
268The kernel's default action for vulnerable processors is:
269
270  - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).
271