| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
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
|
|
|
| |
|
Home