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

>>> On 13.05.11 at 13:20, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
>>> wrote:
> On 05/13/11 13:11, Ian Campbell wrote:
>> On Fri, 2011-05-13 at 12:08 +0100, Joanna Rutkowska wrote:
>>> On 05/13/11 10:08, Jan Beulich wrote:
>>>> 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.
>> Is it even possible to know which guest triggered the MSI, or is the
>> best you can do the set of all guests with an MSI capable device passed
>> through?
> Ah, probably you're right -- if we have more than one driver domain,
> then I think LAPIC would not tell us which device genrated the MSI.

That's why I wrote "killing all guests that potentially could have ...".

> In fact it's not really correct to assume that it must have been a guest
> with a "MSI capable device" -- note that we don't trigger the MSI via
> the official MSI triggering mechanism.

You lost me here. Neither am I clear about what "non-official"
triggering mechanism we use, nor can I see how a guest without
any MSI-capable device would be able to trigger the problem.

And even if things are as you say, it would still seem better to kill
all guests with *any* passed through device, than bring down the
entire host (there could e.g. be dozens of innocent pv guests and
only a single hvm one that has a problematic device assigned).


Xen-devel mailing list

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