[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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. Joe _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |