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

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

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

Very interesting - particularly as it's a different exploit!  I wonder what 
he's come up with.  Hopefully some details will be forthcoming.

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

I don't think we use cpuid for HT info at the moment, although that might 
work.  In general, we'd in any case need a notification from Xen to alert 
domains to CPU topology changes (due repinning, etc.).  This is also an issue 
for migration, but that can hook into the existing notification for that.

I suspect this isn't so much an issue now but may become more important as a) 
Xen runs on larger systems and b) Linux integrates a more topology-aware 
scheduling scheme.

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

Yes, that's true.  Hopefully for most cases this won't be a big issue as long 
as the driver isn't running crypto on behalf of the domains.  I've seen IPSec 
suggested as one potential worry and I guess VLANs, etc could be a problem 
also.

As long as you're not running a crypto service in the driver domain I suspect 
you're (reasonably) safe.  This is another reason to run a slim dom0!

Cheers,
Mark

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