[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



> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: Tuesday, May 24, 2011 9:57 AM
> 
> Cihula, Joseph writes ("RE: [Xen-devel] Xen security advisory CVE-2011-1898 - 
> VT-d (PCI
> passthrough) MSI"):
> > Why do you *need* IR to have a secure Xen w/ TXT?  Certainly a DoS is
> > very undesirable, but that is not really a security issue.
> 
> 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" ;-)

> >  Tell me what security exploits are still possible with the current
> > patches.
> 
> 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?

So if we go back to another point I raised previously...  If you commit your 
patch, what will be your instructions (to users, etc.) for specifying the 
'iommu=' parameters?  I would expect they would be "If your system supports IR 
then specify 'iommu=force'.  If it supports IOMMU but not IR then specify 
'iommu=force,nointremap'." (unless of course you want to say "If it supports 
IOMMU but not IR then throw it away and buy a new one that supports IR or use 
KVM instead.").  Of course, the result is the same as the current 'iommu=force' 
behavior.

> 
> > If someone can present a security issue that TXT
> 
> I don't understand the contribution of TXT to this.  The issue is with 
> running untrusted guest
> kernels.  Necessarily an untrusted guest kernel isn't checked by TXT; that's 
> what "untrusted guest
> kernel"
> means.

TXT does two things:  1) it prevents the SIPI attack (by turning it into a DoS) 
and 2) it prevents malware from tricking Xen into not enabling IR on a system 
that supports it.  The second one is what makes the current 'force' behavior 
the same on an IR system as your patch (i.e. panic/reset).

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.