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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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.

> 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.  This is arguably worth considering for 
anyone who thinks their configuration may be vulnerable to this attack.

> 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).

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).  It is also known to improve performance, presumably because of 
improved cache usage, and cheaper IPIs.

Cheers,
Mark

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