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 Advisory 5 (CVE-2011-3131) IOMMU fault livelock

To: "Tim Deegan" <tim@xxxxxxx>
Subject: Re: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 12 Aug 2011 15:48:04 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Xen.org security team" <security@xxxxxxx>
Delivery-date: Fri, 12 Aug 2011 07:48:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110812140901.GC11708@xxxxxxxxxxxxxxxxxxxxx>
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: <20037.10841.995717.397090@xxxxxxxxxxxxxxxxxxxxxxxx> <4E454C880200007800051000@xxxxxxxxxxxxxxxxxxxx> <20110812140901.GC11708@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 12.08.11 at 16:09, Tim Deegan <tim@xxxxxxx> wrote:
> At 14:53 +0100 on 12 Aug (1313160824), Jan Beulich wrote:
>> > This issue is resolved in changeset 23762:537ed3b74b3f of
>> > xen-unstable.hg, and 23112:84e3706df07a of xen-4.1-testing.hg.
>> Do you really think this helps much? Direct control of the device means
>> it could also (perhaps on a second vCPU) constantly re-enable the bus
>> mastering bit. 
> That path goes through qemu/pciback, so at least lets Xen schedule the
> dom0 tools.

Are you sure? If (as said) the guest uses a second vCPU for doing the
config space accesses, I can't see how this would save the pCPU the
fault storm is occurring on.

> The particular failure that this patch fixes was locking up
> cpu0 so hard that it couldn't even service softirqs, and the NMI
> watchdog rebooted the machine.

Hmm, that would point at a flaw in the interrupt exit path, on which
softirqs shouldn't be ignored.


Xen-devel mailing list