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:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-320 in the XSA Tracker:
---===[ 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)  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 ===========  https://xenbits.xen.org/xsa/advisory-320.html -- The Qubes Security Team https://www.qubes-os.org/security/