tag:blogger.com,1999:blog-8992811497323121233.post2634856051835919127..comments2010-04-26T15:07:36.668-07:00Julien Tinnesnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8992811497323121233.post-33725805332400616532009-06-08T17:52:15.077-07:002009-06-08T17:52:15.077-07:00I agree.<br />If you can already execute code on the host, RDTSC is not a flaw, it&#39;s a tool you might use to exploit flaws.<br /><br />Removing access to it would only make sense if it could not be easily replaced, which is very likely not the case: I expect real-life exploitable flaws to not need that kind of accuracy anyway.<br /><br />Still, I don&#39;t think disabling it in a sandbox is stupid: if you don&#39;t need it, it&#39;s an easier decision to take it away than to decide if you care about it. But removing a useful feature without a proven security benefit should be an option, not something mandatory.Julien Tinneshttp://www.blogger.com/profile/05636781178145883012noreply@blogger.comtag:blogger.com,1999:blog-8992811497323121233.post-13451679026494692042009-05-31T15:53:20.755-07:002009-05-31T15:53:20.755-07:00Side channels are a real problem, but they can often be exploited remotely, which means that disabling TSC locally does not solve anything. For example, I released an advisory about a timing attack on Google Keyczar <A HREF="http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/" REL="nofollow">last week</A>.<br /><br />Besides the RDTSC instruction, you can read the TSC value via MSR 10h. MSRs are privileged though.Nate Lawsonhttp://www.blogger.com/profile/11280644250533859717noreply@blogger.com