cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

tsx_async_abort.rst (11896B)


      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/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 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
    111Best effort mitigation mode
    112^^^^^^^^^^^^^^^^^^^^^^^^^^^
    113
    114If the processor is vulnerable, but the availability of the microcode-based
    115mitigation mechanism is not advertised via CPUID the kernel selects a best
    116effort mitigation mode.  This mode invokes the mitigation instructions
    117without a guarantee that they clear the CPU buffers.
    118
    119This is done to address virtualization scenarios where the host has the
    120microcode update applied, but the hypervisor is not yet updated to expose the
    121CPUID to the guest. If the host has updated microcode the protection takes
    122effect; otherwise a few CPU cycles are wasted pointlessly.
    123
    124The state in the tsx_async_abort sysfs file reflects this situation
    125accordingly.
    126
    127
    128Mitigation mechanism
    129--------------------
    130
    131The kernel detects the affected CPUs and the presence of the microcode which is
    132required. If a CPU is affected and the microcode is available, then the kernel
    133enables the mitigation by default.
    134
    135
    136The mitigation can be controlled at boot time via a kernel command line option.
    137See :ref:`taa_mitigation_control_command_line`.
    138
    139Virtualization mitigation
    140^^^^^^^^^^^^^^^^^^^^^^^^^
    141
    142Affected systems where the host has TAA microcode and TAA is mitigated by
    143having disabled TSX previously, are not vulnerable regardless of the status
    144of the VMs.
    145
    146In all other cases, if the host either does not have the TAA microcode or
    147the kernel is not mitigated, the system might be vulnerable.
    148
    149
    150.. _taa_mitigation_control_command_line:
    151
    152Mitigation control on the kernel command line
    153---------------------------------------------
    154
    155The kernel command line allows to control the TAA mitigations at boot time with
    156the 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
    175Not specifying this option is equivalent to "tsx_async_abort=full". For
    176processors that are affected by both TAA and MDS, specifying just
    177"tsx_async_abort=off" without an accompanying "mds=off" will have no
    178effect as the same mitigation is used for both vulnerabilities.
    179
    180The kernel command line also allows to control the TSX feature using the
    181parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
    182to control the TSX feature and the enumeration of the TSX feature bits (RTM
    183and HLE) in CPUID.
    184
    185The 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
    207Not specifying this option is equivalent to "tsx=off".
    208
    209The following combinations of the "tsx_async_abort" and "tsx" are possible. For
    210affected 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
    227For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
    228buffers.  For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)
    229"tsx" command line argument has no effect.
    230
    231For the affected platforms below table indicates the mitigation status for the
    232combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
    233and 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
    247Mitigation selection guide
    248--------------------------
    249
    2501. Trusted userspace and guests
    251^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    252
    253If all user space applications are from a trusted source and do not execute
    254untrusted code which is supplied externally, then the mitigation can be
    255disabled. The same applies to virtualized environments with trusted guests.
    256
    257
    2582. Untrusted userspace and guests
    259^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    260
    261If there are untrusted applications or guests on the system, enabling TSX
    262might allow a malicious actor to leak data from the host or from other
    263processes running on the same physical core.
    264
    265If the microcode is available and the TSX is disabled on the host, attacks
    266are prevented in a virtualized environment as well, even if the VMs do not
    267explicitly enable the mitigation.
    268
    269
    270.. _taa_default_mitigations:
    271
    272Default mitigations
    273-------------------
    274
    275The kernel's default action for vulnerable processors is:
    276
    277  - Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).