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: Keir Fraser <keir@xxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Tue, 24 May 2011 17:16:42 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 24 May 2011 09:23:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA0193F7.2DA3B%keir@xxxxxxx>
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: <19931.52091.713851.292632@xxxxxxxxxxxxxxxxxxxxxxxx> <CA0193F7.2DA3B%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwaK0dbB1td/JIyDE+h2p2VVYx4ZgAAkVMQ
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
> <sigh> take your pick really. Majority opinion is on the side of this
> revised patch, however Intel are the primary maintainers of this code and
> they clearly do not like it. If I have a casting vote here, I would be
> inclined to plump in favour of the revised patch -- we already have
> iommu=on
> as a best-effort option, and I believe iommu=force could be stronger than it
> is. However Joseph's claim that the non-DoS vulns may all now be handled is
> not as unconvincing as some seem to believe (and I was in that camp for a
> while) -- I can't really see how the attack vector can be successfully
> exploited now my mitigation patch is in the tree. So I'm not strongly
> inclined one way or the other really.

My inclination would be such that iommu=force is allowed on non IR systems, but 
where IR is expected to be present e.g. sandybridge generation we insist that 
it is enabled (i.e. that the BIOS supports it).


Xen-devel mailing list