WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthr

To: Jan Beulich <jbeulich@xxxxxxxxxx>, "Ian.Campbell@xxxxxxxxxx" <Ian.Campbell@xxxxxxxxxx>
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Tue, 17 May 2011 15:52:22 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 May 2011 16:53:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DD235010200007800070074@xxxxxxxxxxxxxxxxxx>
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: <4DD235010200007800070074@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwUZgPueO/GlVzwTRKaWPbHogJB1wARdcmg
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
Sent: Tuesday, May 17, 2011 12:43 AM
To: Ian.Campbell@xxxxxxxxxx; Cihula, Joseph
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

 

>>> "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 05/16/11 11:34 PM >>>
>IOMMU adds security capabilities. IR adds additional security capabilities. IOMMU allows for fully isolating the hypervisor
>from domains even if the domains control DMA devices. It helps to protect against buggy drivers or device FW by limiting
>the areas such bugs can affect to just the DMA data buffers. IOMMU, in conjunction with Intel(R) Trusted Execution
>Technology (TXT), provides DMA protection through the entire launch process and into runtime. This is all true regardless
>of the presence of IR. IR adds the ability to prevent DoS attacks by untrusted domains with assigned DMA devices,
>malicious device FW, etc. This is incremental--not all or nothing.

I think this is the problem - you're saying things like "fully isolating" and "regardless of the presence of IR", while the paper they made accessible

[JC]  I will admit to being a little overreaching in use of that adverb; let’s remove “fully” and my statement still stands.

 

meanwhile makes clear that neither is true. Thus the mere presence of DMA protection creates false expectation of customers - without IR (and with MSI supported by the system, not necessarily the device passed through) there's no way for isolation to become complete (actually, with non-MSI-capable devices or by disallowing MSI altogether on capable ones, depending of whether MSI writes bypass the IOMMU or simply get 1:1 translated, it could be possible to make this secure).

[JC]  The expectations of users will depend on the features advertised and how they are implemented in the SW solutions that use IOMMU.  Such SW should not be advertising DoS protection if devices are assigned to untrusted domains on systems without IR.  Just like it should not advertise that on systems without IOMMU.  (Note that the DMA protection of IOMMU should prevent most/all accidental/buggy behaviors; MSI DoS would almost certainly have to be due to malicious code.)

 

>The 00-block-msis-on-trap-vectors patch (esp. in conjunction with TXT) prevents all known security exploits of MSI misuse.

All? Not really, just a very small subset, and only partially. The SIPI one is perhaps the worst case (not prevented by this patch), but being able to send SMI or NMI perhaps isn't much better (as long as we're considering DoS attacks to also be a problem, which at least I do, and in which case said patch only converts from one [worse] to another ["better"] evil).
[JC]  I didn’t say “all exploits”—I said all *known* exploits, and that is correct.  The SIPI attack, which isn’t known to be exploitable, is prevented by TXT (hence the “esp. in conjunction with TXT” in my statement).  Naturally, DoS attacks are problematic from a reliability perspective but they were not what I was referring to with the term “security exploit”.

 

I still fail to see an argument that justifies panic’ing Xen when IOMMU is enabled on non-IR systems.  And I don’t think the way to manage customer expectations is through SW freezing.

 


Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel