[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.