[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |