Re: [Xen-devel] HT Vulnerability CAN-2005-0109

[David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>]

Mark Williamson wrote:
> Sorry I've taken so long to respond!
>
> > > > It's clear that it is very exploitable.
> > > On a real world system?
> > Yes.
> I'd be more convinced by a record of a successful exploit on a less restricted 
> workload.  A simplified example for exposition of the problem can still be 
> provided.
Note that Adi Shamir also independently came up with an exploit for this
problem (reported at the Cryptographer's Panel at the RSA security conference
in February 2005), although I don't know the details. See Olin Sibert's
RISKS post at <http://catless.ncl.ac.uk/Risks/23.88.html#subj4>.

> > I think the FreeBSD fix implements the approach suggested in the paper of
> > not scheduling threads with different privileges on the same HT processor.
> For now I think they've just disabled HT (by default) whilst figuring out what 
> the best fix is for the long term.
Yes, you're right:
<ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch>

> > In Xen, this would correspond to only giving any particular domain a whole
> > HT processor. I'm not sure how that would affect performance; it could
> > result in only one thread of an HT processor being used in some cases, but
> > OTOH cache utilization might improve in others.
> Yeah, I'd agree with that.  HT is always a bit of a mixed bag wrt performance
>
> I suspect it's actually more useful from a performance PoV to give a domain 
> two HT threads so it at least has the option of doing some clever scheduling 
> (rather than two domains that don't know about each other).  Ideally, we'd 
> export CPU topology info to the domains so that they can be aware of this (I 
> don't know if we do this right now?  Linux Scheddomains would be able to use 
> this).
I would think that as long as "cpuid" works (or is replaced by a hypercall),
a domain running an HT-aware OS should be able to figure this out in the same
way it does for real hardware.

> The other option is to give one thread to a domU and the other thread to a 
> driver domain (e.g. dom0).  This is safe (in the sense it doesn't make things 
> any worse) since domains that control real hardware can abuse DMA to read 
> memory anyway (plus at the moment they have the ability to map domain memory 
> directly).
However, the domU could spy on the driver domain in that case. How significant
this is depends on what device it is, and whether the driver domain is running
any code vulnerable to side channel analysis.

--
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>


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