-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory CVE-2019-11135 / XSA-305
TSX Asynchronous Abort speculative side channel
This is very closely related to the Microarchitectural Data Sampling
vulnerabilities from May 2019.
Please see https://xenbits.xen.org/xsa/advisory-297.html for details
A new way to sample data from microarchitectural structures has been
identified. A TSX Asynchronous Abort is a state which occurs between a
transaction definitely aborting (usually for reasons outside of the
pipeline's control e.g. receiving an interrupt), and architectural state
being rolled back to start of the transaction.
During this period, speculative execution may be able to infer the value
of data in the microarchitectural structures.
For more details, see:
An attacker, which could include a malicious untrusted user process on a
trusted guest, or an untrusted guest, can sample the content of
recently-used memory operands and IO Port writes.
This can include data from:
* A previously executing context (process, or guest, or
hypervisor/toolstack) at the same privilege level.
* A higher privilege context (kernel, hypervisor, SMM) which
interrupted the attacker's execution.
Vulnerable data is that on the same physical core as the attacker. This
includes, when hyper-threading is enabled, adjacent threads.
An attacker cannot use this vulnerability to target specific data. An
attack would likely require sampling over a period of time and the
application of statistical methods to reconstruct interesting data.
Systems running all versions of Xen are affected.
Only x86 processors are vulnerable.
ARM processors are not believed to be vulnerable.
Only Intel based processors are affected. Processors from other
manufacturers (e.g. AMD) are not believed to be vulnerable.
Only Intel processors supporting TSX (Transactional Synchronization
eXtensions) are affected.
Systems which have the XSA-297 (MDS) fixes, and do not enumerate
MDS_NO (Hardware fixes to MDS) are not vulnerable to TAA (XSA-305).
(Specifically, the XSA-297 changes of using VERW flushing and disabling
HyperThreading will prevent data leakage via both MDS and TAA.)
If the XSA-297 Xen patches for MDS have been applied, Xen will
identify at boot if the CPU reports MDS_NO. i.e.
[root@localhost ~]# xl dmesg | grep MDS_NO
(XEN) Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD MD_CLEAR IBRS_ALL RDCL_NO SKIP_L1DFL MDS_NO
Support for TSX is reported by Linux (>=3.4) as `hle' and `rtm' in the
cpu flags (`grep -e hle -e rtm /proc/cpuinfo'). (Note that applying
Option A from Resolution, below, will disable TSX so suppressing this
report, even if the CPU would be vulnerable with TSX enabled.)
In summary: systems which support TSX and enumerate MDS_NO are
vulnerable to XSA-305 (TAA).
There is no mitigation available.
New microcode is required in all cases. It may be available via a
firmware update (consult your hardware vendor), or available for
boot-time loading (consult your dom0 OS vendor).
There are two approaches:
* Upgrade to the new microcode.
* Apply the Xen patches (listed below).
This will disable TSX (by default, but reenabling it would
reintroduce the vulnerability). This option is the recommended
* Upgrade to the new microcode.
* Boot Xen with `smt=0 spec-ctrl=md-clear'.
* (The patches are not strictly required.)
This option is recommended only if it is known that the workload is
such that it is important to retain the TSX feature.
`smt=0' disables hyper-threading, and will have a significant
performance impact. See `DISCUSSION CONCERNING SMT/HYPER-THREADING'
in XSA-297 for more information about the implications and options.
Note that the Xen command line argument `spec-ctrl=md-clear' must be
specified to mitigate XSA-305, even though some readings of XSA-297
suggest it might be enabled by default when needed. This is because
Option B reuses the same mitigation for a new problem.
`spec-ctrl=md-clear' is the default on CPUs vulnerable to XSA-297;
however, it is not the default on CPUs vulnerable to XSA-305.
In each case with the Xen patches applied, appropriate microcode can
be observed by finding TSX_CTRL enumerated:
[root@localhost ~]# xl dmesg | grep TSX_CTRL
(XEN) Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD MD_CLEAR IBRS_ALL RDCL_NO SKIP_L1DFL MDS_NO TSX_CTRL
There is no further action (beyond Option A or B above) required for
guest kernel/userspace software, and nothing they could do differently
to protect themselves in the absence of those changes.
xsa305/xsa305-4.12-*.patch Xen 4.12.x
xsa305/xsa305-4.11-*.patch Xen 4.11.x
xsa304/xsa304-4.10-*.patch Xen 4.10.x
xsa304/xsa304-4.9-*.patch Xen 4.9.x
xsa304/xsa304-4.8-*.patch Xen 4.8.x
$ sha256sum xsa305*/*
NOTE REGARDING LACK OF EMBARGO
Despite an attempt to organise predisclosure, the discoverers ultimately
did not authorise a predisclosure.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Xen-users mailing list
xsa305/xsa305-1.patch (11K) Download Attachment
xsa305/xsa305-2.patch (11K) Download Attachment
xsa305/xsa305-4.8-1.patch (15K) Download Attachment
xsa305/xsa305-4.8-2.patch (12K) Download Attachment
xsa305/xsa305-4.9-1.patch (13K) Download Attachment
xsa305/xsa305-4.9-2.patch (11K) Download Attachment
xsa305/xsa305-4.10-1.patch (12K) Download Attachment
xsa305/xsa305-4.10-2.patch (11K) Download Attachment
xsa305/xsa305-4.11-1.patch (12K) Download Attachment
xsa305/xsa305-4.11-2.patch (11K) Download Attachment
xsa305/xsa305-4.12-1.patch (12K) Download Attachment
xsa305/xsa305-4.12-2.patch (11K) Download Attachment
|Free forum by Nabble||Edit this page|