This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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?


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:

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

<Prev in Thread] Current Thread [Next in Thread>