This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Joanna Rutkowska" <joanna@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 13 May 2011 13:29:11 +0100
Cc: Keir Fraser <keir@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Fri, 13 May 2011 05:29:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DCD1120.5020606@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <19915.58644.191837.671729@xxxxxxxxxxxxxxxxxxxxxxxx> <4DCD030902000078000412C8@xxxxxxxxxxxxxxxxxx> <4DCD1120.5020606@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


> 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

<Prev in Thread] Current Thread [Next in Thread>