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] Xen security advisory CVE-2011-1898 - VT-d (PCI passthro

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Tue, 24 May 2011 12:23:21 -0700
Accept-language: en-US
Acceptlanguage: en-US
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Tue, 24 May 2011 12:23:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19931.58184.270083.947086@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: <4DD235010200007800070074@xxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1305708848.20907.109.camel@xxxxxxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B77B4CAF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110520101715.GB27118@xxxxxxxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B77B5016@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20110522181417.GA4990@xxxxxxxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B77B5973@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19931.58184.270083.947086@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwaM48kQk0HBbgbRRGjkQdK8iyilwAAbfZQ
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Tuesday, May 24, 2011 9:57 AM
> 
> Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-1898 - 
> VT-d (PCI
> passthrough) MSI"):
> > Why do you *need* IR to have a secure Xen w/ TXT?  Certainly a DoS is
> > very undesirable, but that is not really a security issue.
> 
> I'm afraid that a DoS is very much a security issue.

Or a reliability/availability issue.  It clearly is not in the same class as 
security issues that allow for code injection, privilege escalation, etc.  You 
might even consider this as "fail secure" ;-)

> >  Tell me what security exploits are still possible with the current
> > patches.
> 
> As I understand it, a DoS (host crash) is still possible.

So you would rather cause the DoS as soon as Xen is run (via the panic) instead 
of if a guest actually tries to use an MSI attack?  How does that make the 
system more secure?

So if we go back to another point I raised previously...  If you commit your 
patch, what will be your instructions (to users, etc.) for specifying the 
'iommu=' parameters?  I would expect they would be "If your system supports IR 
then specify 'iommu=force'.  If it supports IOMMU but not IR then specify 
'iommu=force,nointremap'." (unless of course you want to say "If it supports 
IOMMU but not IR then throw it away and buy a new one that supports IR or use 
KVM instead.").  Of course, the result is the same as the current 'iommu=force' 
behavior.

> 
> > If someone can present a security issue that TXT
> 
> I don't understand the contribution of TXT to this.  The issue is with 
> running untrusted guest
> kernels.  Necessarily an untrusted guest kernel isn't checked by TXT; that's 
> what "untrusted guest
> kernel"
> means.

TXT does two things:  1) it prevents the SIPI attack (by turning it into a DoS) 
and 2) it prevents malware from tricking Xen into not enabling IR on a system 
that supports it.  The second one is what makes the current 'force' behavior 
the same on an IR system as your patch (i.e. panic/reset).

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

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