Xen.org security team
2013-Feb-05 13:15 UTC
Xen Security Advisory 36 (CVE-2013-0153) - interrupt remap entries shared and old ones not cleared on AMD IOMMUs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2013-0153 / XSA-36
version 3
interrupt remap entries shared and old ones not cleared on AMD IOMMUs
UPDATES IN VERSION 3
===================
Public release.
ISSUE DESCRIPTION
================
To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system. This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.
Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.
In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.
IMPACT
=====
A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.
VULNERABLE SYSTEMS
=================
Xen versions 3.3 onwards are vulnerable. Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.
Only systems using AMD-Vi for PCI passthrough are vulnerable.
Any domain which is given access to a PCI device can take advantage of
this vulnerability.
MITIGATION
=========
This issue can be avoided by not assigning PCI devices to untrusted
guests.
In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor. This option is not fully functional on earlier
hypervisors.
RESOLUTION
=========
Applying the appropriate attached patch resolves this issue.
Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore. This should be dealt with by a BIOS
update, if available. Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.
xsa36-unstable.patch Xen unstable
xsa36-4.2.patch Xen 4.2.x
xsa36-4.1.patch Xen 4.1.x
$ sha256sum xsa36*.patch
2254fa46dcbc164d2d55ad9d519e7aa4ac5b83e9fb8d8e1f224114d08fe44237
xsa36-4.1.patch
6848712b560b522f7d3cede53e29e799624311e7dee6e450f0c02c165a590783
xsa36-4.2.patch
0e5d53c0b2bbbf07ef07bf31d8adeca4c043c0277f122f74557b018dc7348b74
xsa36-unstable.patch
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJREQItAAoJEIP+FMlX6CvZapMH/i+AeMV4Mi9EAe97JWto2xrg
bCBdq7LEJ1cIpXGbhpXwTRzmsEGJmFR2VwkaxEtk+BuC7bzJ/KRjWYg6viQ7v+0t
thHEMtaRYTOIIel8YZ5t+v8oMdEUos7Oo94xhCk+n7ioH6PO+quUTI+aGd0+lcJm
d/5TC5f8w+HZNTB0nCQX9tQx5d4veQXghKs1NbKHeMyZ66nMZiqUqVUwQNTaFhUO
9eWyGOik5/mFctRrMxoOZHQm3d36AnDisiOku2CaG1xYYwDaAnOe/u6QcBZcVX3M
Q9COmTAWnOfIKYMIFnXRnyHSiw2+oZL6PTD5nX4O68B6hZ8pemVa+lFhSTvxsXM=5jP3
-----END PGP SIGNATURE-----
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
Xen.org security team
2013-Feb-21 14:23 UTC
Xen Security Advisory 36 (CVE-2013-0153) - interrupt remap entries shared and old ones not cleared on AMD IOMMUs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Xen Security Advisory CVE-2013-0153 / XSA-36
version 4
interrupt remap entries shared and old ones not cleared on AMD IOMMUs
UPDATES IN VERSION 4
===================
Updated patches, to deal with a boot time crash resulting from the earlier
changes on systems with firmware broken in a way not previously accounted
for.
ISSUE DESCRIPTION
================
To avoid an erratum in early hardware, the Xen AMD IOMMU code by
default chooses to use a single interrupt remapping table for the
whole system. This sharing implies that any guest with a passed
through PCI device that is bus mastering capable can inject interrupts
into other guests, including domain 0.
Furthermore, regardless of whether a shared interrupt remapping table
is in use, old entries are not always cleared, providing opportunities
(which accumulate over time) for guests to inject interrupts into
other guests, again including domain 0.
In a typical Xen system many devices are owned by domain 0 or driver
domains, leaving them vulnerable to such an attack. Such a DoS is
likely to have an impact on other guests running in the system.
IMPACT
=====
A malicious domain which is given access to a physical PCI device can
mount a denial of service attack affecting the whole system.
VULNERABLE SYSTEMS
=================
Xen versions 3.3 onwards are vulnerable. Earlier Xen versions do not
implement interrupt remapping, and hence do not support secure AMD-Vi
PCI passthrough in any case.
Only systems using AMD-Vi for PCI passthrough are vulnerable.
Any domain which is given access to a PCI device can take advantage of
this vulnerability.
MITIGATION
=========
This issue can be avoided by not assigning PCI devices to untrusted
guests.
In Xen versions 4.1.3 and above the sharing of the interrupt remapping
table (and hence the more severe part of this problem) can be avoided
by passing "iommu=amd-iommu-perdev-intremap" as a command line option
to the hypervisor. This option is not fully functional on earlier
hypervisors.
RESOLUTION
=========
Applying the appropriate attached patch resolves this issue.
Note that on certain systems (SP5100 chipsets with erratum 28 present,
or such with broken IVRS ACPI table) these patches will result in the
IOMMU not being enabled anymore. This should be dealt with by a BIOS
update, if available. Alternatively the check can be overridden by
specifying "iommu=no-amd-iommu-perdev-intremap" on the Xen command
line ("iommu=amd-iommu-global-intremap" on 4.1.x), at the price of
re-opening the security hole addressed by these patches.
xsa36-unstable.patch Xen unstable
xsa36-4.2.patch Xen 4.2.x
xsa36-4.1.patch Xen 4.1.x
$ sha256sum xsa36*.patch
4bdc0f1f94f82c6bc6c777971f22ef915215b72b98b29f9064e4df65c0efc6f4
xsa36-4.1.patch
dd32ecaa84edbf6d11241045f40ba53ec4a3bc6c24f719bc21204067c4eb8964
xsa36-4.2.patch
7c0b3a1b332a24a830c7a436b065943f60c54cd5b7e746c440e2992a7b5cfe41
xsa36-unstable.patch
$
Incremental patches on top of what was provided in version 3 can also be
taken from the respective mercurial trees:
http://xenbits.xen.org/hg/xen-unstable.hg/rev/e68f14b9e739
http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg/rev/6a03b38b9cd6
http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/4d522221fa77
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJRJf98AAoJEIP+FMlX6CvZ5ocH/jNY92kLw7BOencxa9R3TGTn
20O0+j1id+xi2vjVVF2xm2SJ7g/6Egx5WURUfy2cu+I8GdDHKmRrp3Vkazltzcnd
6AlI5aiPC2H1rFkU0FpneRk3mrluABLZO8Q5YcSJs24hwqded0W+SivH63aInki/
PsDGoBu8HUjYMWjXyqCJVJIGToLS9ApaQ8+iTylWb1ZocRm2VcPS8yJI7z82kj3A
zRNADG36oAFawSJsE9z3ykVoYv9UYckOaWkaXh7jZPHAvIjvP2wLb9gmMkMXbIOP
ICpJJFf0w7oW6KTY3g9n8CxUMBMoUw/9Fv+CQBzOf0ZZY/vIE8q65A0NhCcWixo=vmpB
-----END PGP SIGNATURE-----
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
Seemingly Similar Threads
- IOMMU/AMD-Vi not working after XSA-36 with 970A-UD3
- AMD IOMMU intremap tables and IOAPICs
- Latest AMD, IOMMU Security Change causing CPU0 Panic and general Problems with AMD+IOMMU changes
- AMD IOMMU disabled - No Perdev Intremap
- XSA-36 / howto fix broken IVRS ACPI table