Re: [Xen-devel] Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock

[Tim Deegan <tim@xxxxxxx>]

At 15:48 +0100 on 12 Aug (1313164084), Jan Beulich wrote:
> >>> 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.

Hmmm.  Yes, I see what you mean.  What was your concern about
memory-mapped config registers?  That PCIback would need to be involved
somehow?

> > 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.

Are you suggesting that we should handle softirqs before re-enabling
interrupts?  That sounds perilous.

Tim.

-- 
Tim Deegan <tim@xxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel