Xen Security Advisory 390 v1 (CVE-2021-28710) - certain VT-d IOMMUs may not work in shared page table mode

[Xen.org security team <security@xxxxxxx>]

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

            Xen Security Advisory CVE-2021-28710 / XSA-390

      certain VT-d IOMMUs may not work in shared page table mode

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

For efficiency reasons, address translation control structures (page
tables) may (and, on suitable hardware, by default will) be shared
between CPUs, for second-level translation (EPT), and IOMMUs.  These
page tables are presently set up to always be 4 levels deep.  However,
an IOMMU may require the use of just 3 page table levels.  In such a
configuration the lop level table needs to be stripped before
inserting the root table's address into the hardware pagetable base
register.  When sharing page tables, Xen erroneously skipped this
stripping.  Consequently, the guest is able to write to leaf page
table entries.

IMPACT
======

A malicious guest may be able to escalate its privileges to that of
the host.

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

Xen version 4.15 is vulnerable.  Xen versions 4.14 and earlier are not
vulnerable.

Only x86 Intel systems with IOMMU(s) in use are affected.  Arm
systems, non-Intel x86 systems, and x86 systems without IOMMU are not
affected.

Only HVM guests with passed-through PCI devices and configured to share
IOMMU and EPT page tables are able to leverage the vulnerability on
affected hardware.  Note that page table sharing is the default
configuration on capable hardware.

Systems are only affected if the IOMMU used for a passed through
device requires the use of page tables less than 4 levels deep.  We
are informed that this is the case for some at least Ivybridge and
earlier "client" chips; additionally it might be possible for such a
situation to arise when Xen is running nested under another
hypervisor, if an (emulated) Intel IOMMU is made available to Xen.

MITIGATION
==========

Suppressing the use of shared page tables avoids the vulnerability.
This can be achieved globally by passing "iommu=no-sharept" on the
hypervisor command line.  This can also be achieved on a per-guest basis
via the "passthrough=sync_pt" xl guest configuration file option.

RESOLUTION
==========

Applying the attached patch resolves this issue.

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.

xsa390.patch           xen-unstable - Xen 4.15.x

$ sha256sum xsa390*
34d3b59a52c79bd7f9d963ca44ee5cfee08274d49961726e81c34eeff6e6cd37  xsa390.patch
$

CREDITS
=======

This issue was discovered by Jan Beulich of SUSE.

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

This fix for issue was submitted in public before realizing the security
aspect.
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmGXsGUMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZiMkH/2t+q/yAO7srnKdt1yLhOcG/tok0pdSLe5b3ayES
ZktW69wnSlQ/TeH96A64pZKxXbQpRh3cDbjn2xedCDGIOyaKuObgPY7aYfuvtOxN
/6a3P3qUf2oxm5/nS0KG6kHX69gptXupvgCPwl2i1KWARi4uMEm76N7lCe3o8fFd
s8HNfLvJ0tX6pXtOQjeQEt73fDWQ/hwKGGJctFI1hrvy01erqHDdZrYiJAO6vp8z
c9LU1o8dIQSUg2dm5GSX5DCX6xEzOh6sT53CDQ7W5gTn+SnCGr7FT1iTeXYeTFSN
EaYZVynkaxQeCXsoJO0K2o7lwwKvUrQ6GNhqdd4iOR/annY=
=P/qb
-----END PGP SIGNATURE-----

Attachment: xsa390.patch
Description: Binary data