All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com,
	"Xen.org security team" <security@xen.org>
Subject: Re: Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock
Date: Tue, 16 Aug 2011 08:03:33 +0100	[thread overview]
Message-ID: <4E4A32650200007800051651@nat28.tlf.novell.com> (raw)
In-Reply-To: <20110815092608.GD11708@ocelot.phlegethon.org>

>>> On 15.08.11 at 11:26, Tim Deegan <tim@xen.org> wrote:
> At 15:48 +0100 on 12 Aug (1313164084), Jan Beulich wrote:
>> >>> On 12.08.11 at 16:09, Tim Deegan <tim@xen.org> 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

  parent reply	other threads:[~2011-08-16  7:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-12 13:27 Xen Advisory 5 (CVE-2011-3131) IOMMU fault livelock Xen.org security team
2011-08-12 13:53 ` Jan Beulich
2011-08-12 14:09   ` Tim Deegan
2011-08-12 14:48     ` Jan Beulich
2011-08-15  9:26       ` Tim Deegan
2011-08-15 10:02         ` Jan Beulich
2011-08-16  7:03         ` Jan Beulich [this message]
2011-08-16 15:06           ` Tim Deegan
2011-08-16 15:59             ` Jan Beulich
2011-09-21  0:07               ` Kay, Allen M
2011-09-21  6:47                 ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E4A32650200007800051651@nat28.tlf.novell.com \
    --to=jbeulich@novell.com \
    --cc=security@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.