[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] HT Vulnerability CAN-2005-0109
Sorry I've taken so long to respond! > >>It's clear that it is very exploitable. > > > > On a real world system? > > Yes. 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. > 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. This is arguably worth considering for anyone who thinks their configuration may be vulnerable to this attack. > 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). 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). It is also known to improve performance, presumably because of improved cache usage, and cheaper IPIs. Cheers, Mark _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |