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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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)

Ian.

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