On 05/13/11 10:08, Jan Beulich wrote: >>>> On 12.05.11 at 15:48, Ian Jackson 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@lists.xensource.com > http://lists.xensource.com/xen-devel