-----BEGIN PGP SIGNED MESSAGE-----
Xen security advisory CVE-2011-1898
VT-d (PCI passthrough) MSI trap injection
Intel VT-d chipsets without interrupt remapping do not prevent a guest
which owns a PCI device from using DMA to generate MSI interrupts by
writing to the interrupt injection registers. This can be exploited
to inject traps and gain control of the host.
You are not vulnerable if you do not use "PCI passthrough". That is,
if you do not pass actual PCI devices (eg, graphics and network
controllers) through to guests, for use by PCI device drivers in the
In Xen with xend/xm or with xl this would be enabled by the "pci="
option in the domain config file, or by using the "xl pci-attach" or
"xm pci-attach" management command; if you do not use these features,
you are not vulnerable.
You are not vulnerable if you are using PCI passthrough, but are not
using Intel VT-d or AMD-Vi (aka "iommu") to attempt to prevent escape
by guest DMA. This is because in such a configuration, privilege
escalation and denial of service are possible by guests anyway, and
the present issue does not make the situation any worse.
You are vulnerable if you use Intel VT-d to pass PCI devices through
to untrusted guests, unless your have interrupt remapping supported
and enabled. This is the case whether you are using Xen, KVM, or
another virtualisation system.
Interrupt remapping is available in newer Intel VT-d chipsets.
A guest given a PCI passthrough device can escalate its privilege and
gain control of the whole system.
MITIGATION AND RESOLUTION
No complete software fix is available but we understand that Intel has
addressed this issue with newer hardware.
We believe a patch along the lines of the one attached can be applied
to Xen to reduce the impact to a denial of service. Even with such a
patch, a guest can still cause a complete system crash or resource
Upgrading to recent hardware that is interrupt remapping capable will
resolve the remaining denial of service issues. Support for interrupt
remapping, when the hardware is capable, is present in all currently
maintained versions of Xen.
On such recent hardware, when passing pci devices through to untrusted
guests, we recommend the use of the "iommu=required" Xen command line
boot option and the second atttached patch, to avoid unknowingly
booting into a vulnerable configuration.
Thanks to Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab
for bringing this issue to our attention. Their paper on the attack
will soon be available from Invisible Things Lab, at
Information regarding chipset versions and interrupt remapping support
should be available from Intel; please use your usual support and
security response channels at Intel.
We believe that this vulnerability exists with all virtualisation
systems which aim to support passing pci devices through to
untrusted guests, on the affected Intel hardware. If you are using
a hypervisor other than Xen please refer to your hypervisor's usual
security support and advisory release channels.
The first patch is intended to reduce the impact from full privilege
escalation to denial of service.
The second patch is intended to ensure that when Xen boots with
"iommu=required" it will also insist that interrupt remapping is
supported and enabled. It arranges that booting with that option on
vulnerable hardware will fail, rather than appearing to succeed but
actually being vulnerable to guests.
Unfortunately we have not been able to test either patch. Both will
be applied to xen-unstable very soon. We also intend to provide
backports in the supported released Xen trees.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
-----END PGP SIGNATURE-----
Description: mitigation patch for old hardware
Description: assurance patch for new hardware
Xen-devel mailing list