-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen Security Advisory CVE-2013-3495 / XSA-59
                              version 4

 Intel VT-d Interrupt Remapping engines can be evaded by native NMI interrupts

UPDATES IN VERSION 4
====================

Public release.

Extensive changes to Description, Vulnerable Systems and Mitigation.
Additional technical information has been supplied by the vendor, Intel.

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

Message Signaled Interrupts (MSI) interrupts on Intel platforms are defined as
DWORD writes to a special address location (0xFEE?????). MSIs on Intel
Platforms supporting VT-d have two defined formats - Remappable format
interrupts, and Compatibility (not remappable) format interrupts, based on the
format of their data payload. Remappable interrupts are subject to
interrupt-remapping protection checks, while compatibility format interrupts
are not. For protection reasons, host software disables compatibility format
interrupts (causing them to be blocked by interrupt translation hardware) and
manages the remappable interrupts through programming of interrupt-remapping
table entries.

Malformed MSIs are transactions to the special (0xFEE?????) address range that
do not have proper attributes of MSI requests (e.g., size of request is
invalid). Such malformed transactions are detected and aborted by the platform,
before they are subject to further interrupt remapping/processing. For RAS
purposes, some platforms may be configured to support System Error Reporting
(SERR) capability. These platforms raise a PCI system error (SERR#) due to
Unsupported Request, which are typically delivered as Non-Maskable Interrupts
(NMI), to report such errors to software.  Depending on hypervisor and Dom0
kernel configuration, such an NMI may be handled by the hypervisor/Dom0 or can
result in a host software halt ("panic"). On platforms with SERR enabled, such
malformed MSI requests can be generated by guest OS with an assigned device,
causing hypervisor/Dom0 receive NMI despite using VT-d and interrupt remapping
for device assignment.

IMPACT
======

A malicious domain, given access to a device which bus mastering capable, can
mount a denial of service attack affecting the whole system.

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

Xen version 3.3 onwards is vulnerable.

Only systems using Intel VT-d for PCI passthrough are vulnerable where system
firmware (BIOS) may enable SERR in Host Bridge device. In order to verify
whether SERR is enabled, one can read the SERR Enable (SERRE) bit (bit 8) in
PCICMD register (offset 0x4) in PCI configuration space of the Host Bridge
device (BDF 00:00.0). Value 1 of PCICMD[SERRE] indicates SERR logic is enabled.

It is currently not known whether all or just some chipsets supporting VT-d are
affected.

Any domain which is given access to a PCI device that is bus mastering capable
can take advantage of this vulnerability.

MITIGATION
==========

This issue can be avoided by not assigning PCI devices to untrusted guests.

There are possible workarounds, but none of these have been
implemented at the current time:

A possible workaround is for hypervisor or Dom0 to disable SERR in the
Host Bridge device by clearing SERRE bit in PCICMD register in PCI
configuration space of Host Bridge device (BDF 00:00.0) which will
block all system error messages generated by the Host Bridge. This is
applicable to all chipsets.

Alternatively hypervisor or Dom0 can block SERR error signaling due to
Unsupported Request error resulting from malformed MSI requests by setting bit
20 ("Unsupported Request Error Mask") in memory configuration register at
offset 0x1C8 (DMIUEMSK) in Root Complex Register Range. The base address of
Root Complex Register Range is defined by DMIBAR register (offset 0x68) in PCI
configuration space of the Host Bridge (BDF 00:00.0). For this alternative,
less intrusive workaround it was so far not determined whether it is applicable
to all or just some Intel chipsets.

CREDITS
=======

This vulnerability was discovered by Gábor PÉK (from CrySyS Lab).

RESOLUTION
==========

There is currently no resolution to this issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJSE1wVAAoJEIP+FMlX6CvZVe0H/jyjKdVst3QCLPG7wJXEILVi
K2/Pr8G2N4BnugO34qpPyfh3N81D5jhdwHec75NyXbZ+lbrdSChXYGI72ST8sV7S
kTTnXAZAxf19UemyzF5Mv+mbu5YYgcU/XfOE1z7GBJqYFnD4QxxatlJuABcThl8S
nUvFrRz0Pqg68LqztRMF+Fj16DtgbFO6UrCHoFcs00rolGfx/W9DMnSOntlwhT+u
ajPR+glDGvQSMzer3IVpC6igtH1gCTfc3o8uiPnQRv9oWHfV+D+/GEjClV33gEgI
KhzTnA460gnjDSipNlk9mLI/H0Fk/Ter5zjrKzHZpvF4zr1v5H1eSAGmZ0AmqhQ=
=ochw
-----END PGP SIGNATURE-----