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

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

On 05/13/11 10:08, Jan Beulich wrote:
>>>> 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?
> 

No. That's sort of the key point here, and the reason why IR hardware is
required.

>> 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?
> 

Killing the guest might no longer be enough, because the guest might
have already programmed the device to keep sending malicious MSIs. So,
panic()ing the whole VMM seems like a safer choice. Keep in mind that on
a non-IR hardware there are probably many other ways for the malicious
driver domain to cause global DoS. (In fact, my impression is that most
people regarded IR as an anti-DoS mechanism, and I believe our paper is
the first to show that the problems were far worse than possible DoS.)

joanna.

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

signature.asc
Description: OpenPGP digital signature

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