| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] HT Vulnerability CAN-2005-0109
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
|
|
|
| |
|
Home