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

> 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 

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!


Xen-devel mailing list

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