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

                             2020-10-20


           Multiple Xen issues (XSA-345, XSA-346, XSA-347)


Summary
========

On 2020-10-20, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-345 [1] "x86: Race condition in Xen mapping code":
| The Xen code handling the updating of the hypervisor's own pagetables
| tries to use 2MiB and 1GiB superpages as much as possible to maximize
| TLB efficiency.  Some of the operations for checking and coalescing
| superpages take non-negligible amount of time; to avoid potential lock
| contention, this code also tries to avoid holding locks for the entire
| operation.
| 
| Unfortunately, several potential race conditions were not considered;
| precisely-timed guest actions could potentially lead to the code
| writing to a page which has been freed (and thus potentially already
| reused).
| 
| A malicious guest can cause a host denial-of-service.  Data corruption
| or privilege escalation cannot be ruled out.


XSA-346 [2] "undue deferral of IOMMU TLB flushes":
| To efficiently change the physical to machine address mappings of a
| larger range of addresses for fully virtualized guests, Xen contains
| an optimization to coalesce per-page IOMMU TLB flushes into a single,
| wider flush after all adjustments have been made.  While this is fine
| to do for newly introduced page mappings, the possible removal of
| pages from such guests during this operation should not be "optimized"
| in the same way.  This is because the (typically) final reference of
| such pages is dropped before the coalesced flush, and hence the pages
| may have been put to a different use even though DMA initiated by
| their original owner might still be in progress.
| 
| A malicious guest might be able to cause data corruption and data
| leaks.  Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.


XSA-347 [3] "unsafe AMD IOMMU page table updates":
| AMD IOMMU page table entries are updated in a step by step manner,
| without regard to them being potentially in use by the IOMMU.
| Therefore it was possible that the IOMMU would read and then use a
| half-updated entry.  Furthermore, updates to Device Table entries
| lacked suitable ordering enforcement for certain steps involved in
| these updates.
| 
| In both case the specific outcome heavily depends on how exactly the
| compiler translated the affected pieces of code.
| 
| A malicious guest might be able to cause data corruption and data
| leaks.  Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.


Impact
=======

XSA-345: The default Qubes configuration is safe. Shadow mode for HVM
and PVH domains is disabled at build time, and domains that have PCI
devices run in HVM mode by default. Therefore, we do not consider this
XSA to affect the security of Qubes OS. However, we are including it in
this QSB anyway since it is technically possible for the user to
manually change a domain that has PCI devices from HVM to PV, which
would result in a configuration that is vulnerable to this issue. Having
anticipated the risk associated with such a manual change, we have
already implemented appropriate safeguards. In the Qubes GUI for
changing VM settings, the user would have to go to the "Advanced" tab in
order to change the setting from HVM to PV. Upon making the change, the
user would immediately be confronted with a warning in bold red text
that reads, "Using PV mode exposes more hypervisor attack surface!"
Therefore, it is nearly impossible users would switch to the vulnerable
configuration by accident.

XSA-346, XSA-347: A malicious domain with a PCI device (e.g., sys-net or
sys-usb in the default configuration) could try to exploit this
vulnerability in order to crash the host. Beyond DoS, it is unlikely
that this vulnerability could be exploited to compromise the system, but
we cannot completely rule out the possibility. Both of these issues
apply only to systems running on AMD processors.


Patching
=========

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

  For Qubes 4.0:
  - Xen packages, version 4.8.5-25
  For Qubes 4.1:
  - Xen packages, version 4.14.0-6
  
The packages are to be installed in dom0 via the Qube 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
Xen binaries.


Credits
========

See the original Xen Security Advisories.


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

[1] https://xenbits.xen.org/xsa/advisory-345.html
[1] https://xenbits.xen.org/xsa/advisory-346.html
[1] https://xenbits.xen.org/xsa/advisory-347.html

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