| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthro
>>> On 13.05.11 at 13:08, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
> 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.
So are you saying that the memory transaction triggering the MSI is
indistinguishable from any other DMA operation? Implying that the
guest must be granted access to the page containing the MSI
address the device is to write to? If so, the changes done as a
result of your report are only addressing a (very?) small subset of
bad things such a guest could do.
>>> 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,
Obviously, resetting the devices should be part of killing such guests.
Jan
> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home