Documentation/admin-guide/hw-vuln/tsx_async_abort.rst

   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 potentially 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 Virtualization mitigation
 140 ^^^^^^^^^^^^^^^^^^^^^^^^^
 141
 142 Affected systems where the host has TAA microcode and TAA is mitigated by
 143 having disabled TSX previously, are not vulnerable regardless of the status
 144 of the VMs.
 145
 146 In all other cases, if the host either does not have the TAA microcode or
 147 the kernel is not mitigated, the system might be vulnerable.
 148
 149
 150 .. _taa_mitigation_control_command_line:
 151
 152 Mitigation control on the kernel command line
 153 ---------------------------------------------
 154
 155 The kernel command line allows to control the TAA mitigations at boot time with
 156 the option "tsx_async_abort=". The valid arguments for this option are:
 157
 158   ============  =============================================================
 159   off           This option disables the TAA mitigation on affected platforms.
 160                 If the system has TSX enabled (see next parameter) and the CPU
 161                 is affected, the system is vulnerable.
 162
 163   full          TAA mitigation is enabled. If TSX is enabled, on an affected
 164                 system it will clear CPU buffers on ring transitions. On
 165                 systems which are MDS-affected and deploy MDS mitigation,
 166                 TAA is also mitigated. Specifying this option on those
 167                 systems will have no effect.
 168
 169   full,nosmt    The same as tsx_async_abort=full, with SMT disabled on
 170                 vulnerable CPUs that have TSX enabled. This is the complete
 171                 mitigation. When TSX is disabled, SMT is not disabled because
 172                 CPU is not vulnerable to cross-thread TAA attacks.
 173   ============  =============================================================
 174
 175 Not specifying this option is equivalent to "tsx_async_abort=full". For
 176 processors that are affected by both TAA and MDS, specifying just
 177 "tsx_async_abort=off" without an accompanying "mds=off" will have no
 178 effect as the same mitigation is used for both vulnerabilities.
 179
 180 The kernel command line also allows to control the TSX feature using the
 181 parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
 182 to control the TSX feature and the enumeration of the TSX feature bits (RTM
 183 and HLE) in CPUID.
 184
 185 The valid options are:
 186
 187   ============  =============================================================
 188   off           Disables TSX on the system.
 189
 190                 Note that this option takes effect only on newer CPUs which are
 191                 not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1
 192                 and which get the new IA32_TSX_CTRL MSR through a microcode
 193                 update. This new MSR allows for the reliable deactivation of
 194                 the TSX functionality.
 195
 196   on            Enables TSX.
 197
 198                 Although there are mitigations for all known security
 199                 vulnerabilities, TSX has been known to be an accelerator for
 200                 several previous speculation-related CVEs, and so there may be
 201                 unknown security risks associated with leaving it enabled.
 202
 203   auto          Disables TSX if X86_BUG_TAA is present, otherwise enables TSX
 204                 on the system.
 205   ============  =============================================================
 206
 207 Not specifying this option is equivalent to "tsx=off".
 208
 209 The following combinations of the "tsx_async_abort" and "tsx" are possible. For
 210 affected platforms tsx=auto is equivalent to tsx=off and the result will be:
 211
 212   =========  ==========================   =========================================
 213   tsx=on     tsx_async_abort=full         The system will use VERW to clear CPU
 214                                           buffers. Cross-thread attacks are still
 215                                           possible on SMT machines.
 216   tsx=on     tsx_async_abort=full,nosmt   As above, cross-thread attacks on SMT
 217                                           mitigated.
 218   tsx=on     tsx_async_abort=off          The system is vulnerable.
 219   tsx=off    tsx_async_abort=full         TSX might be disabled if microcode
 220                                           provides a TSX control MSR. If so,
 221                                           system is not vulnerable.
 222   tsx=off    tsx_async_abort=full,nosmt   Ditto
 223   tsx=off    tsx_async_abort=off          ditto
 224   =========  ==========================   =========================================
 225
 226
 227 For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
 228 buffers.  For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)
 229 "tsx" command line argument has no effect.
 230
 231 For the affected platforms below table indicates the mitigation status for the
 232 combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
 233 and TSX_CTRL_MSR.
 234
 235   =======  =========  =============  ========================================
 236   MDS_NO   MD_CLEAR   TSX_CTRL_MSR   Status
 237   =======  =========  =============  ========================================
 238     0          0            0        Vulnerable (needs microcode)
 239     0          1            0        MDS and TAA mitigated via VERW
 240     1          1            0        MDS fixed, TAA vulnerable if TSX enabled
 241                                      because MD_CLEAR has no meaning and
 242                                      VERW is not guaranteed to clear buffers
 243     1          X            1        MDS fixed, TAA can be mitigated by
 244                                      VERW or TSX_CTRL_MSR
 245   =======  =========  =============  ========================================
 246
 247 Mitigation selection guide
 248 --------------------------
 249
 250 1. Trusted userspace and guests
 251 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 252
 253 If all user space applications are from a trusted source and do not execute
 254 untrusted code which is supplied externally, then the mitigation can be
 255 disabled. The same applies to virtualized environments with trusted guests.
 256
 257
 258 2. Untrusted userspace and guests
 259 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 260
 261 If there are untrusted applications or guests on the system, enabling TSX
 262 might allow a malicious actor to leak data from the host or from other
 263 processes running on the same physical core.
 264
 265 If the microcode is available and the TSX is disabled on the host, attacks
 266 are prevented in a virtualized environment as well, even if the VMs do not
 267 explicitly enable the mitigation.
 268
 269
 270 .. _taa_default_mitigations:
 271
 272 Default mitigations
 273 -------------------
 274
 275 The kernel's default action for vulnerable processors is:
 276
 277   - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).