We have just published Qubes Security Bulletin (QSB) #057: Special Register Buffer speculative side channel (XSA-320). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB #057 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-057-2020.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/qsb/

View XSA-320 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#320



             ---===[ Qubes Security Bulletin #57 ]===---

                             2020-06-11


      Special Register Buffer speculative side channel (XSA-320)

Summary
========

On 2020-06-09, the Xen Security Team published Xen Security Advisory
320 (CVE-2020-0543 / XSA-320) [1] with the following 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
| 
| 
| 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).

This is yet another CPU hardware bug related to speculative execution.

Only Intel processors are affected. The RDRAND instruction became
available in Intel processors starting with Ivy Bridge (3rd gen Intel
Core). See Intel's advisory for a full list of affected CPUs. (Short
version: Most mobile/desktop CPUs are affected, while most Atoms and
server Xeons are not.)

Impact
=======

An attacker can obtain data returned by RDRAND/RDSEED instructions on
another core on the system (including another VM). In practice, Linux
does use RDRAND/RDSEED to seed its random number generator
(/dev/urandom, getrandom(2) etc.), but RDRAND/RDSEED is not the only
source of entropy. So, as long as other sources of entropy are not
compromised, the overall security of the random number generator is
still preserved. In Qubes OS, the situation is further improved by
seeding the random number generator at VM startup using a random seed
provided from dom0. This means that using Linux's random number
generator is still safe in Qubes.

Aside from the Linux kernel using RDRAND/RDSEED as one of its entropy
sources, userspace applications can also issue RDRAND/RDSEED
instructions on their own. Such software is also affected by the bug
described here. The specific impact on such software depends on what the
application does with the random data obtained in this manner.

Patching
=========

Intel has provided a microcode update that mitigates the issue. Please
note that Ivy Bridge processors are considered retired by Intel and no
longer receive microcode updates. This means that Ivy Bridge processors
will remain vulnerable to this issue. To mitigate the problem, we are
masking out RDRAND availability to VMs on those affected platforms.

The specific packages that resolve the problems discussed in this
bulletin are as follows:

  For Qubes 4.0:
  - microcode_ctl 2.1-30.qubes1
  - qubes-core-dom0 4.0.51 (needed for Ivy Bridge platforms only)

The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:

  For updates from the stable repository (not immediately available):
  $ sudo qubes-dom0-update

  For updates from the security-testing repository:
  $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
microcode binaries.

Credits
========

See the original Xen Security Advisory.

References
===========

[1] https://xenbits.xen.org/xsa/advisory-320.html

--
The Qubes Security Team
https://www.qubes-os.org/security/