WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] tools/ioemu: Fixing Security Hole in Qemu MSIX t

To: "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] tools/ioemu: Fixing Security Hole in Qemu MSIX table access management
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 25 Aug 2011 12:55:02 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, TimDeegan <Tim.Deegan@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Donald D Dugger <donald.d.dugger@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Haitao Shan <maillists.shan@xxxxxxxxx>
Delivery-date: Thu, 25 Aug 2011 04:54:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20054.11440.90844.633430@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <CAFQ2Z+f+7ax3G63NgvghtjYX3ZucofVYQ6AOtMHaA+dCUT8+-g@xxxxxxxxxxxxxx> <20054.11440.90844.633430@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 25.08.11 at 13:06, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Haitao Shan writes ("[Xen-devel] [PATCH] tools/ioemu: Fixing Security Hole in 
> Qemu MSIX table access management"):
>> As reported by Jan, current Qemu does not handle MSIX table mapping 
> properly.
>> 
>> Details:
>> 
>> MSI-X table resides in one of the physical BARs. When Qemu handles
>> guest's changes to BAR register (within which, MSI-X table resides),
>> Qemu first allows access of the whole BAR MMIO ranges and then removes
>> those of MSI-X. There is a small window here. It is possible that on a
>> SMP guests one vcpu could have access to the physical MSI-X
>> configurations when another vcpu is writing BAR registers.
>> 
>> The patch fixes this issue by first producing the valid MMIO ranges by
>> removing MSI-X table's range from the whole BAR mmio range and later
>> passing these ranges to Xen.
> 
> I'm afraid it wasn't clear to me what the consensus was on the status
> of the attached patch, and I'm not very familiar with the code.

Afaict, the change here removes only the smallest part of problem: Xen
already forces any mapping attempts of the MSI-X table by DomU-s to
be read-only once the respective MSI gets set up, so the window during
which the guest has full access exists only before any MSI gets set up.

> Also, if this is a security problem we should really issue an advisory...

In a larger round on one of the BOFs on the summit we agreed there is
an issue in that the way it currently works, qemu's (on behalf of and
exclusively driven by the guest) direct writing to the mask bit represents
a security problem, since Xen itself needs to be able to force interrupts
masked during certain operations (move_native_irq(), IRQ rate limiting,
2nd instance of already pending guest IRQ, and fixup_irq()), and
failure here would potentially affect the whole system.

My (limited) understanding of qemu-kvm's dealing with that is that they
hide the physical mask bit from the guest altogether, which works
presumably because during normal operation the bit never gets fiddled
with (but in polling mode some network drivers do make use of it, and
I'd expect that not to work under KVM, unless my reading of their
sources was wrong).

Jan


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

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