QSB-081: x86: MMIO Stale Data vulnerabilities (XSA-404)

We have just published Qubes Security Bulletin (QSB) 081: x86: MMIO Stale Data vulnerabilities (XSA-404). 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-081 in the qubes-secpack:


In addition, you may wish to:

             ---===[ Qubes Security Bulletin 081 ]===---


            x86: MMIO Stale Data vulnerabilities (XSA-404)

User action required

Users with appropriate hardware (see the "affected hardware" section
below) must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-41

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.5-3

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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take

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
Xen binaries.


On 2022-06-14, the Xen Project published XSA-404, "x86: MMIO Stale
Data vulnerabilities" [3]:

| This issue is related to the SRBDS, TAA and MDS vulnerabilities.
| Please see:
|   https://xenbits.xen.org/xsa/advisory-320.html (SRBDS)
|   https://xenbits.xen.org/xsa/advisory-305.html (TAA)
|   https://xenbits.xen.org/xsa/advisory-297.html (MDS)
| Please see Intel's whitepaper:
|   https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html


An adversary who controls a VM with an assigned PCI device can infer
the memory content of other guests or Xen itself. This could allow the
adversary to read information that should be accessible only to Xen or
another VM and to use that information to launch further attacks. In
the default Qubes OS configuration, only sys-net and sys-usb can be
used to perform this attack.

Affected hardware

All Intel systems are affected. While mitigations are available, they
are available only for some Intel CPU models. Normally, it should be a
simple matter to look up a given CPU model number in a table to see
whether it is affected and whether it is eligible for any mitigations.
Indeed, Intel has published a table [4] that claims to serve this
purpose. Unfortunately, however, we have found several inaccuracies in
this table. Since we cannot rely on the table, we have had to devise an
alternative method using other published Intel technical documents that
appear to be more accurate. This has turned out to be quite complex.

Our best evidence indicates that mitigations are available for all and
only those CPUs that are both eligible for and updated with the Intel
microcode update released in May 2022. [5] Since going through all the
complicated technical steps of checking this manually would be
excessively cumbersome for most users, we have written a tool that does
it for you. Please note that this tool is entirely optional and is *not*
required for any security updates to take effect. Rather, its intended
purpose is to satisfy the curiosity of users who wish to know whether
their own CPUs are eligible for mitigations and who would struggle to
make that determination manually. This tool is included in the
`qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the
`qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. 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. [1] Once available, the packages are to be installed via the
Qubes Update tool or its command-line equivalents. [2]

After installing the required updates, you will be able to execute `sudo
cpu-microcode-info` in a dom0 terminal. This will output a table of
information about the logical CPUs (aka CPU "cores") in your system. The
"F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes
that Intel uses in its microcode documentation, [5] which is explained
in further detail in Intel's README. [6] (The manual process of checking
would involve extracting your CPU information, converting it to
hexadecimal, and looking it up in the appropriate table in this
document.) The "Loaded microcode version" column lists the microcode
versions currently loaded for each CPU. The "20220510 update available"
column lists whether the required May 2022 microcode update is
*available* for each CPU. The "20220510 update installed" column lists
whether the required May 2022 microcode update is *installed* in each

In order for the updates associated with this bulletin to successfully
mitigate XSA-404, a value of "yes" is required in both of these last two
"20220510 update" columns. If the "available" column has a "yes" while
the "installed" column has a "no," then the May 2022 microcode update
must be installed first. If both columns have "no" values, then this CPU
remains vulnerable, and there is no known mitigation available. If your
system has such a CPU, then installing The Xen packages listed in the
"user action required" section above is *not* expected to mitigate the
problem described in this bulletin. Unfortunately, there is simply
nothing we can do for these CPUs in terms of patching unless we receive
a fix from Intel or receive new information about which CPUs are
affected. Nonetheless, we still recommend installing the updates anyway
(once available), since they will not make the problem any worse,
keeping up-to-date with all security updates is a general best practice,
and future updates will be based on the latest version.

However, hope is not entirely lost for users whose CPUs are not eligible
for software mitigations. Since the vulnerability discussed in this
bulletin does not affect VMs without PCI passthrough devices, users
still have the option of altering their habits to treat VMs like sys-usb
and sys-net as more trusted. While this can be especially challenging in
the case of sys-net, it at least affords users *some* latitude in
working around the problem by being mindful of when such VMs are
running, how trusted their templates are, and similar considerations.

Further plans regarding PCI passthrough

This is yet another issue affecting only VMs with access to PCI devices.
This pattern of vulnerabilities has prompted us to research more secure
ways of handling such VMs in future Qubes releases. Eventually, we plan
to treat them as more privileged VMs that require additional protection.
Specific protective measures will be discussed with the community as
part of our ongoing research and development efforts.


See the original Xen Security Advisory.


[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-404.html
[4] https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html
[5] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20220510
[6] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files#about-processor-signature-family-model-stepping-and-platform-id

The Qubes Security Team

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/06/17/qsb-081/
1 Like

I wonder if unsupported CPUs are also vulnerable. Unfortunately Intels overview (Affected Processors: Transient Execution Attacks & Related Security...) no longer shows 5th gen and older CPUs. Maybe they haven’t been tested since they are EOL, but 5th gen and older have also been removed from the overview for older vulnerabilities.