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


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 [and 2 more messages]
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Wed, 1 Jun 2011 18:06:09 +0000
Accept-language: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Fraser <keir@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Keir
Delivery-date: Thu, 02 Jun 2011 03:03:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19932.54836.362631.885968@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: <19931.52091.713851.292632@xxxxxxxxxxxxxxxxxxxxxxxx> <CA0193F7.2DA3B%keir@xxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA3B2C2ABD055@xxxxxxxxxxxxxxxxxxxxxxxxx> <19931.59237.816706.497141@xxxxxxxxxxxxxxxxxxxxxxxx> <4F65016F6CB04E49BFFA15D4F7B798D901B792DA43@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <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> <4F65016F6CB04E49BFFA15D4F7B798D901B792DA32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19932.54836.362631.885968@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwaxFq5YgZLz2x6RTeKUNKD+VSHpQFI9zSQ
Thread-topic: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI [and 2 more messages]
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Wednesday, May 25, 2011 3:13 AM
> Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-1898 - 
> VT-d (PCI
> passthrough) MSI"):
> > None of the proposed patches check for whether passthrough is being
> > used.  Nor can they check whether it is being used safely (it may be
> > used for performance by domains that are trusted).
> Indeed.  Providing that information is the purpose of the "iommu=required" 
> command line option.
> That option is a declaration by the system administrator: "I will be using 
> PCI passthrough and I
> need it to be secure".
> A better arrangement would to prevent the use of PCI passthrough on insecure 
> systems, at the time
> of device assignment, unless the sysadmin has explicitly specified 
> "pci_passthrough_security=none"
> or something.  But I imagine you would object to that even more.
> > Whether IR is required for a secure system with passthrough depends on
> > the usage model (as I indicated in an earlier email).
> If the usage model does not depend on Xen enforcing VM separation when PCI 
> passthrough is used,
> then "iommu=on" is the correct boot option.
> We are only arguing about the behaviour when "iommu=required".
> >  The user/distributor should decide whether their usage model requires
> > it or not.  If it does, then all they need to do is run on HW that
> > supports IR (and if they're worried about the pre-OS attack then use
> > TXT, which would be necessary anyway).
> If the user has specified "iommu=required" then it is a bug if the system 
> then allows a domain to
> be created with pci passthrough devices in a way that allows the domain to 
> attack the host.
> The user should not be required to take additional steps to ensure that the 
> system is secure.
> Your proposal would have the user have to inspect the boot output from Xen in 
> detail in an effort
> to determine whether the hardware and software they had was working properly.
> (Determining the hardware feature support from marketing literature or 
> pre-sales material is
> obviously not reliable.)
> I'm not sure what you mean by "pre-OS attack".  If you mean the situation 
> with an untrusted guest
> kernel, that is a very common one and does not require the use of TXT.  It 
> simply requires Xen to
> properly enforce the VM boundary.
> Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-1898 - 
> VT-d (PCI
> passthrough) MSI"):
> > Ian Jackson:
> > > 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" ;-)
> I don't want to get into an argument about semantics.  Nevertheless, 
> protection against denial of
> service is a key requirement for most software.  In other software projects, 
> when DoS
> vulnerabilities are found, they issue a security advisory and fix the bug.  
> We should do the same.
> > > 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?
> This is getting ridiculous.  I'm really starting to become quite cross.  
> Please stop blocking the
> correct behaviour just because it's politically inconvenient.
> (rest of my draft email snipped)

We'll just have to agree to disagree.  So that said, Ian's (Campbell) last 
patch should undo the conditional coalescing.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI [and 2 more messages], Cihula, Joseph <=