CVE-2019-11135 - Transactional Synchronization Extensions (TSX) Asynchronous Abort
Overview
Transactional Synchronization Extensions (TSX) Asynchronous Abort is an MDS-style flaw affecting the same buffers that the previous MDS-style vulnerability was able to affect. A local attacker using custom code can use this flaw to gather information from cache contents on the processor and sibling logical processors on processors that support simultaneous multithreading (SMT) and TSX.
The flaw found in the implementation of Intel TSX abortion where a local authenticated attacker, with the ability to monitor execution time of TSX regions, is able to infer memory state by comparing abort execution times.
This could allow information disclosure via this observed side channel while an attacker is able to observe abort timing of the transaction.
This issue has been assigned CVE-2019-11135 and is rated Moderate.
Background
TSX - is a CPU feature that provides a software interface for designating code regions for transactional execution. This feature allows a processor to determine whether threads that are running concurrently need to be serialized and avoid lock contention.
TSX was designed to improve the performance of these marked transaction code regions by monitoring all running threads for conflicting memory accesses and aborting a transaction when a conflict was found.
When a transaction was aborted the executed code would fall back to an existing traditional lock mechanism to complete the transaction in a method defined by the software.
A flaw was found in the implementation of Intel TSX abortion where a local authenticated attacker, with the ability to monitor execution time of TSX regions, is able to infer memory state by comparing abort execution times.
This could allow information disclosure via this observed side channel while an attacker is able to observe abort timing of the transaction.
Previous MDS patches applied to the kernel can mitigate this flaw while enabled on systems affected by MDS with an updated kernel.
Newer CPUs not affected by MDS will need a kernel update to completely mitigate this issue as the MDS mitigations were not enabled for this hardware.
One way of mitigating TAA issue is to disable TSX feature of the CPU, so that TSX Asynchronous Abort (TAA) would not occur, and in turn the said information leakage via speculative side channel would not occur. The kernel update introduces a new kernel boot parameter ‘tsx=on/off/auto’ to enable OR disable CPU’s Transactional Synchronization Extensions(TSX) feature. It requires microcode updates to be installed.
tsx=on Enable the TSX feature <= RHEL Default
tsx=off Disable the TSX feature
tsx=auto Disable TSX if CPU is affected, else enable TSX
Second way of mitigating TAA issue is to clear CPU buffers upon context switch. Buffers such as Store Buffer, Fill Buffer etc. which hold data during instruction execution. The kernel update introduces another parameter, ‘tsx_async_abort=off/full/full,nosmt’, to control how the kernel clears CPU buffers to mitigate the TAA issue.
tsx_async_abort=off Disable TAA mitigation
tsx_async_abort=full Enable TAA mitigations, clears CPU buffers
tsx_async_abort=full,nosmt Enable TAA mitigations and disable SMT
Not specifying this parameter, enables the mitigation with tsx_async_abort=full. If SMT is enabled, a thread on one logical processor of a CPU core maybe able to infer data of the sibling thread on the same core. For such cases, tsx_async_abort=full,nosmt is offered.
Updated kernel provides a sysfs interface below for users to know whether the system is affected and state of the applied mitigations
$ cat /sys/devices/system/cpu/vulnerabilities/tsx_async_abort
Vulnerable
Vulnerable: Clear CPU buffers attempted, no microcode
Mitigation: Clear CPU buffers, SMT vulnerable
Mitigation: TSX disabled
Not affected
Affected Products
The following Red Hat product versions are impacted:
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Atomic Host
- Red Hat OpenShift Online
- Red Hat Virtualization (RHV)
- Red Hat OpenStack Platform (images shipping kernel)
While Red Hat's Linux Containers are not directly impacted by third-party hardware vulnerabilities, their security relies upon the integrity of the host kernel environment. Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers. To protect the privacy of the containers in use, you will need to ensure that the Container host (such as Red Hat Enterprise Linux, RHEL CoreOS or Atomic Host) has been updated against these attacks.
Determine Vulnerability
Diagnose your vulnerability
Use the detection script to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well. How to use GPG to verify signed content from Product Security.
Download the Detection Script
Current version: 1.0
Resolution
Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately and reboot to mitigate this flaw correctly.
Frequently Asked Questions
Q: Does the update need to be applied to both guests and hosts?
A: Yes, much like the original spectre v1, this can be used to create attacks across VMs that share logical siblings.
Q: Do I need to reboot after updating the kernel?
A: Yes.
Q: I have applied previous Spectre-v1, Spectre-v2, and MDS fixes do I need to apply this also?
A: Yes. While MDS can mitigate this on some systems, newer CPUs not affected by MDS will require this update. If you are unsure, apply the update as it includes other security fixes.
Q: Are any other security patches included with this update ?
A: Yes, the i915 graphics card CVE’s are included on platforms where required.
Q: Can I disable this security mitigation?
A: One mitigation works by disabling TSX at boot time, this mitigation can be disabled by explicitly enabling the TSX feature by passing tsx=on parameter to the kernel at boot time. It can not be changed at run time.
Second mitigation works by clearing CPU buffers via VERW mechanism. This can be disabled by setting tsx_async_abort=off.
Acknowledgements
Red Hat thanks Intel and their industry partner for reporting this issue. Red Hat would also like to acknowledge researchers referenced here Intel-SA-00270
Comments