From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cihula, Joseph" Subject: RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI [and 2 more messages] Date: Wed, 1 Jun 2011 18:06:09 +0000 Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDACFFF3@ORSMSX101.amr.corp.intel.com> References: <19931.52091.713851.292632@mariner.uk.xensource.com> <4FA716B1526C7C4DB0375C6DADBC4EA3B2C2ABD055@LONPMAILBOX01.citrite.net> <19931.59237.816706.497141@mariner.uk.xensource.com> <4F65016F6CB04E49BFFA15D4F7B798D901B792DA43@orsmsx506.amr.corp.intel.com> <4DD235010200007800070074@vpn.id2.novell.com> <4F65016F6CB04E49BFFA15D4F7B798D901B773E6D1@orsmsx506.amr.corp.intel.com> <1305708848.20907.109.camel@zakaz.uk.xensource.com> <4F65016F6CB04E49BFFA15D4F7B798D901B77B4CAF@orsmsx506.amr.corp.intel.com> <20110520101715.GB27118@whitby.uk.xensource.com> <4F65016F6CB04E49BFFA15D4F7B798D901B77B5016@orsmsx506.amr.corp.intel.com> <20110522181417.GA4990@whitby.uk.xensource.com> <4F65016F6CB04E49BFFA15D4F7B798D901B77B5973@orsmsx506.amr.corp.intel.com> <19931.58184.270083.947086@mariner.uk.xensource.com> <4F65016F6CB04E49BFFA15D4F7B798D901B792DA32@orsmsx506.amr.corp.intel.com> <19932.54836.362631.885968@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <19932.54836.362631.885968@mariner.uk.xensource.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: "xen-devel@lists.xensource.com" , Fraser , Tim Deegan , Ian Campbell , Ian Pratt , Keir List-Id: xen-devel@lists.xenproject.org > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Wednesday, May 25, 2011 3:13 AM >=20 > Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-18= 98 - 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). >=20 > Indeed. Providing that information is the purpose of the "iommu=3Drequir= ed" command line option. > That option is a declaration by the system administrator: "I will be usin= g PCI passthrough and I > need it to be secure". >=20 > A better arrangement would to prevent the use of PCI passthrough on insec= ure systems, at the time > of device assignment, unless the sysadmin has explicitly specified "pci_p= assthrough_security=3Dnone" > or something. But I imagine you would object to that even more. >=20 > > Whether IR is required for a secure system with passthrough depends on > > the usage model (as I indicated in an earlier email). >=20 > If the usage model does not depend on Xen enforcing VM separation when PC= I passthrough is used, > then "iommu=3Don" is the correct boot option. > We are only arguing about the behaviour when "iommu=3Drequired". >=20 > > 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). >=20 > If the user has specified "iommu=3Drequired" then it is a bug if the syst= em then allows a domain to > be created with pci passthrough devices in a way that allows the domain t= o attack the host. >=20 > The user should not be required to take additional steps to ensure that t= he system is secure. > Your proposal would have the user have to inspect the boot output from Xe= n in detail in an effort > to determine whether the hardware and software they had was working prope= rly. > (Determining the hardware feature support from marketing literature or pr= e-sales material is > obviously not reliable.) >=20 > 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. I= t simply requires Xen to > properly enforce the VM boundary. >=20 > Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-18= 98 - 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" ;-) >=20 > I don't want to get into an argument about semantics. Nevertheless, prot= ection against denial of > service is a key requirement for most software. In other software projec= ts, when DoS > vulnerabilities are found, they issue a security advisory and fix the bug= . We should do the same. >=20 > > > 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? >=20 > This is getting ridiculous. I'm really starting to become quite cross. = Please stop blocking the > correct behaviour just because it's politically inconvenient. >=20 > (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