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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> "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 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).

>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).

Jan

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