RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI [and 2 more messages]

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

> 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.

Joe

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