This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthro

To: "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>, "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 13 May 2011 09:08:09 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 13 May 2011 01:09:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19915.58644.191837.671729@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <19915.58644.191837.671729@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 12.05.11 at 15:48, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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.

Isn't that (or at least can't that be) prevented with DMA remapping?

> The first patch is intended to reduce the impact from full privilege
> escalation to denial of service.
>  Filename: 00-block-msis-on-trap-vectors
>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9

You modify only 64-bit and only VT-d code here. While I know you
don't care much for it, doing the same for 32-bit would seem trivial.

As to AMD's IOMMU, it may well be that interrupt re-mapping isn't
optional in the hardware (albeit it can be disabled on the command
line, though that's the admin's security risk then), but the code
having BUG_ON()s on failed allocations and those allocations
happening in table parsing callbacks doesn't really make this
explicit (for me at least) on the first glance.

Finally, wouldn't killing all guests that potentially could have caused
the problem be a better measure than bringing down the host?


Xen-devel mailing list