Information

Files

Advisory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2020-0543 / XSA-320
                              version 2

           Special Register Buffer speculative side channel

UPDATES IN VERSION 2
====================

Add a link to Intel's cross reference of affected hardware.

Provide a suggested workaround for Ivy Bridge hardware, which is not
receiving a microcode update.  This includes a 3rd patch for each
release.

ISSUE DESCRIPTION
=================

This issue is related to the MDS and TAA vulnerabilities.  Please see
https://xenbits.xen.org/xsa/advisory-297.html (MDS) and
https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details.

Certain processor operations microarchitecturally need to read data from
outside the physical core (e.g. to communicate with the random number
generator).  In some implementations, this operation is called a Special
Register Read.

In some implementations, data are staged in a single shared buffer, and
a full cache line at a time is returned to the core which made the
Special Register Read.  On parts vulnerable to MFBDS or TAA, an attacker
may be able to access stale data requested by other cores in the system.

For more details, see:
  https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html
  https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model

IMPACT
======

An attacker, which could include a malicious untrusted user process on a
trusted guest, or an untrusted guest, can sample the contents of
certain off-core accesses by other cores in the system.

This can include data whose use may depend on the secrecy of the value,
such as data from the Random Number Generator (e.g. RDRAND/RDSEED
instructions).

VULNERABLE SYSTEMS
==================

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.

Please consult the Intel Security Advisory for details on the affected
processors.

MITIGATION
==========

Disabling RDRAND (and, where applicable, RDSEED) will avoid the
vulnerability.  It may have other adverse consequences, such as guests
generating keys with weak random numbers, or guests hanging during
boot waiting for entropy.

A domain (guest, dom0, or service domain) which is runs with RDRAND
disabled in CPUID, and whose software conforms to normal feature
detection as specified in the Intel/AMD manuals, will not be
vulnerable to snooping by other domains.  But such a domain *can*
still potentially snoop on any domains which are still using RDRAND.

This mitigation is recommended to be applied globally, due to the
practical complexity of auditing all software in a VM to confirm that
there are no vulnerable uses of the RDRAND/RDSEED instructions.

RDRAND and RDSEED can be disabled at the host level by booting Xen
with `cpuid=no-rdrand,no-rdseed`, which will hide the feature from all
domains including guests and dom0.  Xen 4.12 and earlier require the
appropriate patch 3 below for this mechanism to work.

RDRAND and RDSEED can be disabled for guests with the following
setting in the VM configuration file (xl.cfg):
  cpuid=["host:rdrand=0,rdseed=0]"
(NB it would have to be merged into any existing cpuid= setting). Xen
4.9 and earlier require the appropriate patch 3 below for this
mechanism to work.

RESOLUTION
==========

New microcode is being released on some affected parts to work around
the vulnerability.  It may be available via a firmware update (consult
your hardware vendor), or available for OS loading (consult your dom0 OS
vendor).

For Ivy Bridge hardware, which is not receiving a microcode update, see
MITIGATION, above.

On Xen 4.13 and later, OS microcode can be loaded at runtime. See
https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading
for details on the xen-ucode utility.

Loading the microcode, either at boot or at runtime, suffices to
mitigate the issue, as protections are active by default.  The
mitigations do have an impact on latency of individual RDRAND/RDSEED
instructions.

The patches below are for Xen, and offer boot time information,
defaults selection, opt-out controls, and uniform controls for hiding
the RDRAND/RDSEED instructions.

Note that patches for released versions are generally prepared to apply
to the stable branches, and may not apply cleanly to the most recent
release tarball.  Downstreams are encouraged to update to the tip of the
stable branch before applying these patches.

xsa320/xsa320-?.patch        xen-unstable
xsa320/xsa320-4.13-?.patch   Xen 4.13.x
xsa320/xsa320-4.12-?.patch   Xen 4.12.x
xsa320/xsa320-4.11-?.patch   Xen 4.11.x
xsa320/xsa320-4.10-?.patch   Xen 4.10.x
xsa320/xsa320-4.9-?.patch    Xen 4.9.x

$ sha256sum xsa320*/*
84e4f66492042b08e69b0894ea7feb20c17c89a696cf95f05a8826fba4f26355  xsa320/xsa320-1.patch
5a3a06c72d0281fa1191ba18e39b836d2748400d9bf6a59dd45447850530c88b  xsa320/xsa320-2.patch
fd15c8a5098ce70af85c6cf1f69f1e6b51eabfda0a0bb780b27f47a8ae44e3a2  xsa320/xsa320-3.patch
759259ef88c980363d44e11d9c272f6a4a15918e5e6bcdfe971b1ce7ea160cd9  xsa320/xsa320-4.9-1.patch
ebac2c011841c55c3c1e99d9e8afc53e56e54268d379ec8b904f6bfe6a1a5045  xsa320/xsa320-4.9-2.patch
3aeade2c9bb1fe77f6c076d531378d3971aa44cdb87996bda27565fa6e707bd2  xsa320/xsa320-4.9-3.patch
5c622c74358ab21cbd27484c649f26df0f08e89ec333c346415bc51e35ba26c1  xsa320/xsa320-4.10-1.patch
f112e34a6a4564a043926fc255a15c7e319001bd023a97ae2947228024e1c306  xsa320/xsa320-4.10-2.patch
1ff6f34840ddb23b7f9bad5e2a1a5cf5246a55219ce7f686f2d80b3dc55e2960  xsa320/xsa320-4.10-3.patch
f24b51292be0cb5de80c6eff0b26983629dd48cc39ae5a331e2e38e15a6cf712  xsa320/xsa320-4.11-1.patch
03579810eaf2e9eeb1a82de4b50ff5c4b01e60b30ccf7609c9e3378ef576d81e  xsa320/xsa320-4.11-2.patch
fa4bcb5422a43395bfe57b8e324b80e447b004eb24360b78343577de0f247067  xsa320/xsa320-4.11-3.patch
282537ffe2fd4332c0e061ddc537bea3e135a7bbd9253ec298becb49047323cf  xsa320/xsa320-4.12-1.patch
e4417429297354c233e8f5c261aff4888aae602f8c68897c09b16ea1aa44b1ca  xsa320/xsa320-4.12-2.patch
dd374e6c11c54c4077895132b8cc5771d3193df2febde643fcef94f973ee409e  xsa320/xsa320-4.12-3.patch
611f2ab1a1c67e04767188d9803b6afd7d304e81a5b4f1eb1744d3e8a68ced66  xsa320/xsa320-4.13-1.patch
cd1bc0071e72e2342ff4508ea3d937988694f4c03506b3afb3184f7d81aa1c86  xsa320/xsa320-4.13-2.patch
1fe0437059bac1fcc4be44ec3c9f9b53f4c5568c8f02c3f2aa2e452febe39cd1  xsa320/xsa320-4.13-3.patch
$

NOTE REGARDING LACK OF EMBARGO
==============================

Despite an attempt to organise predisclosure, the discoverers ultimately
did not authorise a predisclosure.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl7iLP8MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZYSMIAISQRxbfSDYpTKAObAGn7Jhv4rGM4C0gYagFWKxb
eLuhvWZN49uPuyIfsO8WfZxAQJTP2hEDNd4ncFYwS7JbD/F/RCsYFgiasw/aqCUX
9vEkRtrvD7XvIe0DWAjHUrvaFvnjI/vl03D3kxQw15eDPXU8pQMPrfva6W1PrQfv
+b+aQHiawR6MPawCraK3kfCs1dTEnrkH+vL5h+nnEyB34ciTG+Z1g3Rhx7GMh6+7
tb9VLOPZMRvvCRii3pRBolcT0MmZAcakbBxCixMDo7bSEaw3G7Zro2RO9MvvsoFF
r1Pa8IC8kVTWQTi8CYS46E1TvQ7yr86ERejaFQs0fk6vxhI=
=N8eC
-----END PGP SIGNATURE-----