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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 15.08.11 at 11:26, Tim Deegan <tim@xxxxxxx> wrote:
> 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.

Actually, a second vCPU may not even be needed: Since the "fault"
really is an external interrupt, if that one gets handled on a pCPU other
than the one the guest's vCPU is running on, it could execute such a
loop even in that case.

As to yesterdays softirq-based handling thoughts - perhaps the clearing
of the bus master bit on the device should still be done in the actual IRQ
handler, while the processing of the fault records could be moved out to
a softirq.

Jan


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