278 lines
12 KiB
ReStructuredText
278 lines
12 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
TAA - TSX Asynchronous Abort
|
|
======================================
|
|
|
|
TAA is a hardware vulnerability that allows unprivileged speculative access to
|
|
data which is available in various CPU internal buffers by using asynchronous
|
|
aborts within an Intel TSX transactional region.
|
|
|
|
Affected processors
|
|
-------------------
|
|
|
|
This vulnerability only affects Intel processors that support Intel
|
|
Transactional Synchronization Extensions (TSX) when the TAA_NO bit (bit 8)
|
|
is 0 in the IA32_ARCH_CAPABILITIES MSR. On processors where the MDS_NO bit
|
|
(bit 5) is 0 in the IA32_ARCH_CAPABILITIES MSR, the existing MDS mitigations
|
|
also mitigate against TAA.
|
|
|
|
Whether a processor is affected or not can be read out from the TAA
|
|
vulnerability file in sysfs. See :ref:`tsx_async_abort_sys_info`.
|
|
|
|
Related CVEs
|
|
------------
|
|
|
|
The following CVE entry is related to this TAA issue:
|
|
|
|
============== ===== ===================================================
|
|
CVE-2019-11135 TAA TSX Asynchronous Abort (TAA) condition on some
|
|
microprocessors utilizing speculative execution may
|
|
allow an authenticated user to potentially enable
|
|
information disclosure via a side channel with
|
|
local access.
|
|
============== ===== ===================================================
|
|
|
|
Problem
|
|
-------
|
|
|
|
When performing store, load or L1 refill operations, processors write
|
|
data into temporary microarchitectural structures (buffers). The data in
|
|
those buffers can be forwarded to load operations as an optimization.
|
|
|
|
Intel TSX is an extension to the x86 instruction set architecture that adds
|
|
hardware transactional memory support to improve performance of multi-threaded
|
|
software. TSX lets the processor expose and exploit concurrency hidden in an
|
|
application due to dynamically avoiding unnecessary synchronization.
|
|
|
|
TSX supports atomic memory transactions that are either committed (success) or
|
|
aborted. During an abort, operations that happened within the transactional region
|
|
are rolled back. An asynchronous abort takes place, among other options, when a
|
|
different thread accesses a cache line that is also used within the transactional
|
|
region when that access might lead to a data race.
|
|
|
|
Immediately after an uncompleted asynchronous abort, certain speculatively
|
|
executed loads may read data from those internal buffers and pass it to dependent
|
|
operations. This can be then used to infer the value via a cache side channel
|
|
attack.
|
|
|
|
Because the buffers are potentially shared between Hyper-Threads cross
|
|
Hyper-Thread attacks are possible.
|
|
|
|
The victim of a malicious actor does not need to make use of TSX. Only the
|
|
attacker needs to begin a TSX transaction and raise an asynchronous abort
|
|
which in turn potentially leaks data stored in the buffers.
|
|
|
|
More detailed technical information is available in the TAA specific x86
|
|
architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`.
|
|
|
|
|
|
Attack scenarios
|
|
----------------
|
|
|
|
Attacks against the TAA vulnerability can be implemented from unprivileged
|
|
applications running on hosts or guests.
|
|
|
|
As for MDS, the attacker has no control over the memory addresses that can
|
|
be leaked. Only the victim is responsible for bringing data to the CPU. As
|
|
a result, the malicious actor has to sample as much data as possible and
|
|
then postprocess it to try to infer any useful information from it.
|
|
|
|
A potential attacker only has read access to the data. Also, there is no direct
|
|
privilege escalation by using this technique.
|
|
|
|
|
|
.. _tsx_async_abort_sys_info:
|
|
|
|
TAA system information
|
|
-----------------------
|
|
|
|
The Linux kernel provides a sysfs interface to enumerate the current TAA status
|
|
of mitigated systems. The relevant sysfs file is:
|
|
|
|
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
|
|
|
|
The possible values in this file are:
|
|
|
|
.. list-table::
|
|
|
|
* - 'Vulnerable'
|
|
- The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.
|
|
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
|
|
- The system tries to clear the buffers but the microcode might not support the operation.
|
|
* - 'Mitigation: Clear CPU buffers'
|
|
- The microcode has been updated to clear the buffers. TSX is still enabled.
|
|
* - 'Mitigation: TSX disabled'
|
|
- TSX is disabled.
|
|
* - 'Not affected'
|
|
- The CPU is not affected by this issue.
|
|
|
|
.. _ucode_needed:
|
|
|
|
Best effort mitigation mode
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
If the processor is vulnerable, but the availability of the microcode-based
|
|
mitigation mechanism is not advertised via CPUID the kernel selects a best
|
|
effort mitigation mode. This mode invokes the mitigation instructions
|
|
without a guarantee that they clear the CPU buffers.
|
|
|
|
This is done to address virtualization scenarios where the host has the
|
|
microcode update applied, but the hypervisor is not yet updated to expose the
|
|
CPUID to the guest. If the host has updated microcode the protection takes
|
|
effect; otherwise a few CPU cycles are wasted pointlessly.
|
|
|
|
The state in the tsx_async_abort sysfs file reflects this situation
|
|
accordingly.
|
|
|
|
|
|
Mitigation mechanism
|
|
--------------------
|
|
|
|
The kernel detects the affected CPUs and the presence of the microcode which is
|
|
required. If a CPU is affected and the microcode is available, then the kernel
|
|
enables the mitigation by default.
|
|
|
|
|
|
The mitigation can be controlled at boot time via a kernel command line option.
|
|
See :ref:`taa_mitigation_control_command_line`.
|
|
|
|
Virtualization mitigation
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Affected systems where the host has TAA microcode and TAA is mitigated by
|
|
having disabled TSX previously, are not vulnerable regardless of the status
|
|
of the VMs.
|
|
|
|
In all other cases, if the host either does not have the TAA microcode or
|
|
the kernel is not mitigated, the system might be vulnerable.
|
|
|
|
|
|
.. _taa_mitigation_control_command_line:
|
|
|
|
Mitigation control on the kernel command line
|
|
---------------------------------------------
|
|
|
|
The kernel command line allows to control the TAA mitigations at boot time with
|
|
the option "tsx_async_abort=". The valid arguments for this option are:
|
|
|
|
============ =============================================================
|
|
off This option disables the TAA mitigation on affected platforms.
|
|
If the system has TSX enabled (see next parameter) and the CPU
|
|
is affected, the system is vulnerable.
|
|
|
|
full TAA mitigation is enabled. If TSX is enabled, on an affected
|
|
system it will clear CPU buffers on ring transitions. On
|
|
systems which are MDS-affected and deploy MDS mitigation,
|
|
TAA is also mitigated. Specifying this option on those
|
|
systems will have no effect.
|
|
|
|
full,nosmt The same as tsx_async_abort=full, with SMT disabled on
|
|
vulnerable CPUs that have TSX enabled. This is the complete
|
|
mitigation. When TSX is disabled, SMT is not disabled because
|
|
CPU is not vulnerable to cross-thread TAA attacks.
|
|
============ =============================================================
|
|
|
|
Not specifying this option is equivalent to "tsx_async_abort=full". For
|
|
processors that are affected by both TAA and MDS, specifying just
|
|
"tsx_async_abort=off" without an accompanying "mds=off" will have no
|
|
effect as the same mitigation is used for both vulnerabilities.
|
|
|
|
The kernel command line also allows to control the TSX feature using the
|
|
parameter "tsx=" on CPUs which support TSX control. MSR_IA32_TSX_CTRL is used
|
|
to control the TSX feature and the enumeration of the TSX feature bits (RTM
|
|
and HLE) in CPUID.
|
|
|
|
The valid options are:
|
|
|
|
============ =============================================================
|
|
off Disables TSX on the system.
|
|
|
|
Note that this option takes effect only on newer CPUs which are
|
|
not vulnerable to MDS, i.e., have MSR_IA32_ARCH_CAPABILITIES.MDS_NO=1
|
|
and which get the new IA32_TSX_CTRL MSR through a microcode
|
|
update. This new MSR allows for the reliable deactivation of
|
|
the TSX functionality.
|
|
|
|
on Enables TSX.
|
|
|
|
Although there are mitigations for all known security
|
|
vulnerabilities, TSX has been known to be an accelerator for
|
|
several previous speculation-related CVEs, and so there may be
|
|
unknown security risks associated with leaving it enabled.
|
|
|
|
auto Disables TSX if X86_BUG_TAA is present, otherwise enables TSX
|
|
on the system.
|
|
============ =============================================================
|
|
|
|
Not specifying this option is equivalent to "tsx=off".
|
|
|
|
The following combinations of the "tsx_async_abort" and "tsx" are possible. For
|
|
affected platforms tsx=auto is equivalent to tsx=off and the result will be:
|
|
|
|
========= ========================== =========================================
|
|
tsx=on tsx_async_abort=full The system will use VERW to clear CPU
|
|
buffers. Cross-thread attacks are still
|
|
possible on SMT machines.
|
|
tsx=on tsx_async_abort=full,nosmt As above, cross-thread attacks on SMT
|
|
mitigated.
|
|
tsx=on tsx_async_abort=off The system is vulnerable.
|
|
tsx=off tsx_async_abort=full TSX might be disabled if microcode
|
|
provides a TSX control MSR. If so,
|
|
system is not vulnerable.
|
|
tsx=off tsx_async_abort=full,nosmt Ditto
|
|
tsx=off tsx_async_abort=off ditto
|
|
========= ========================== =========================================
|
|
|
|
|
|
For unaffected platforms "tsx=on" and "tsx_async_abort=full" does not clear CPU
|
|
buffers. For platforms without TSX control (MSR_IA32_ARCH_CAPABILITIES.MDS_NO=0)
|
|
"tsx" command line argument has no effect.
|
|
|
|
For the affected platforms below table indicates the mitigation status for the
|
|
combinations of CPUID bit MD_CLEAR and IA32_ARCH_CAPABILITIES MSR bits MDS_NO
|
|
and TSX_CTRL_MSR.
|
|
|
|
======= ========= ============= ========================================
|
|
MDS_NO MD_CLEAR TSX_CTRL_MSR Status
|
|
======= ========= ============= ========================================
|
|
0 0 0 Vulnerable (needs microcode)
|
|
0 1 0 MDS and TAA mitigated via VERW
|
|
1 1 0 MDS fixed, TAA vulnerable if TSX enabled
|
|
because MD_CLEAR has no meaning and
|
|
VERW is not guaranteed to clear buffers
|
|
1 X 1 MDS fixed, TAA can be mitigated by
|
|
VERW or TSX_CTRL_MSR
|
|
======= ========= ============= ========================================
|
|
|
|
Mitigation selection guide
|
|
--------------------------
|
|
|
|
1. Trusted userspace and guests
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
If all user space applications are from a trusted source and do not execute
|
|
untrusted code which is supplied externally, then the mitigation can be
|
|
disabled. The same applies to virtualized environments with trusted guests.
|
|
|
|
|
|
2. Untrusted userspace and guests
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
If there are untrusted applications or guests on the system, enabling TSX
|
|
might allow a malicious actor to leak data from the host or from other
|
|
processes running on the same physical core.
|
|
|
|
If the microcode is available and the TSX is disabled on the host, attacks
|
|
are prevented in a virtualized environment as well, even if the VMs do not
|
|
explicitly enable the mitigation.
|
|
|
|
|
|
.. _taa_default_mitigations:
|
|
|
|
Default mitigations
|
|
-------------------
|
|
|
|
The kernel's default action for vulnerable processors is:
|
|
|
|
- Deploy TSX disable mitigation (tsx_async_abort=full tsx=off).
|