|Public release ||2015-03-10 12:00|
|Updated ||2015-03-10 12:00|
|CVE(s) ||none (yet) assigned|
|Title ||Non-standard PCI device functionality may render pass-through insecure|
Filesadvisory-124.txt (signed advisory file)
-----BEGIN PGP SIGNED MESSAGE-----
Xen Security Advisory XSA-124
Non-standard PCI device functionality may render pass-through insecure
UPDATES IN VERSION 2
Clarify scope. PCI config space backdoors are just one example.
Provide more examples of potential problems. Provide some additional
Devices with capabilities or defects that are undocumented or that
virtualization software is unaware of may allow guests to control
parts of the host that they shouldn't be in control of. Here are some
examples of the kind of problem:
* While XSA-120 deals with standard PCI config space accesses to the
PCI control word, various devices have alternative methods to read
and modify config space values. A guest which has been given such a
device can definitely cause a host DoS; worse attacks cannot be
* Devices which are physically integrated into the system chipset
might have undocumented direct access to memory or other resources
(as well as the documented access via the IOMMU). A guest with such
a device is likely to be able to gain control of the host.
* Many devices permit (or require) the loading or updating of the
firmware on the device. Bad firmware is likely to be able to
violate the PCI protocols (depending on the physical circuitry on
the device). The impact of such violations is difficult to assess
in the abstract.
Malicious firmware might also be able to cause electrical problems
for the PCI bus, system power supply, and other circuitry. This
could be used to mount fault-injection attacks, or even to cause
damage to hardware.
Again, this will depend on the details of the device, but in general
defending against bad firmware would require additional electronics.
Therefore the Xen Project Security Team expects that devices which
support firmware loading are unlikely to be robust against malicious
firmware unless that robustness has been specifically engineered.
Since the details are device specific, special workarounds would need
to be developed for any such device for which secure pass-through is
desired. Developing such workarounds is a task presenting multiple
challenges, particularly since the hardware details are often not
officially documented, and is beyond the scope of normal security
The Xen Project Security Team is therefore adopting an exceptional
process for these kind of problems. See below for details of that
exceptional process, and for the scope of the exception.
Passing through a device providing such mechanisms, which bypass or
subvert the software layers that ensure security and correctness, may
expose the host to guest induced information leaks, host crashes, and
Only systems where physical PCI devices are passed through to
untrusted guests are affected.
All hypervisors supporting PCI passthrough are exposed to this kind of
problem; this includes all versions of Xen which support PCI
Only x86 Xen systems are currently affected. ARM systems are not
currently affected when running Xen due to not supporting
pass-through. However once this feature is implemented ARM systems
will become vulnerable to this class of bugs and subject to the
exceptional handling described in this advisory.
Devices specifically designed and advertised for secure PCI
passthrough (for example, SR-IOV virtual functions) are outside the
scope of this advisory, and outside the process exception. We are not
aware of problems with any such devices at the present time, and any
vulnerabilities which we become aware of will be handled in the normal
Any other PCI devices might cause vulnerablities, and are subject to
the exception. Whether a specific system is actually vulnerable
depends on the characteristics of the PCI device being passed through:
* The device behaviour will usually depend on the specific firmware
loaded onto the device itself; if such firmware is (or can be)
loaded by guests, the device is probably vulnerable (unless its
manufacturer has specifically advertised to the contrary).
* Other devices should be assumed to be vulnerable unless the complete
functionality is known, and has been reviewed in the context of PCI
Not passing through any physical devices to guests will avoid this
This vulnerability can also be avoided by only passing through devices
the entire scope of whose functionality is known and has been reviewed
for PCI passthrough security and correctness, or only devices
specifically and correctly designed to be passed through in a secure
manner (for example, SR-IOV virtual functions).
If the functionality of a PCI device needs to be exposed to an
untrusted guest, PCI passthrough related vulnerabilities can be
avoided by offering the guest that functionality via a higher-level
protocol. For example: rather than PCI passthrough of a storage
controller, offer the guest Xen paravirtualised block devices, or
configure the guest as a client for a SAN protocol (such as NBD or
iSCSI); rather than passing through a graphics controller, provide the
guest with a Xen paravirtualised framebuffer, or have the guest export
applications via a network terminal protocol (such as X11 or VNC).
For affected devices, no reasonable resolution in software is
"Unreasonable" resolution might be possible for specific devices,
where the complete scope of the device's functionality is known. In
such a case it might be possible to write device-specific workaround
code to eliminate the vulnerabilities. The Xen Project Security Team
does not intend to develop software along those lines.
NOTE REGARDING CVE
MITRE have provisionally concluded that this Xen Security Advisory
does not describe a vulnerability for which they should issue a CVE
PROCESS FOR HARDWARE RELATED PASS-THROUGH VULNERABILITIES
Unless affected hardware is specifically declared to be secure when
used with PCI passthrough, the Xen Project Security Team intends
(subject of course to the permission of anyone disclosing to us) to
handle these and future hardware related PCI pass-through
vulnerabilities in public, as if they were normal non-security-related
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----
Xenproject.org Security Team