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