4

In 2005, Colin Percival discovered and presented a security flaw with then newly-introduced hyper-threading on Intel Pentium 4 processors, which, in summary, says (from abstract):

...shared access to memory caches provides not only an easily used high bandwidth covert channel between threads, but also permits a malicious thread (operating, in theory, with limited privileges) to monitor the execution of another thread, allowing in many cases for theft of cryptographic keys.

In 2006, (as a result of the discovery?) Intel removed hyper-threading from Core microarchitecture, introduced in the same year.

In 2008, Intel re-introduced hyper-threading in the new Nehalem microarchitecture.

Although it's not entirely clear from the quoted sources whether the removal of hyper-threading from Core and re-introduction in Nehalem was in order to fix the issue, does anybody know whether and/or how Intel eventually fixed the issue?

Leo Heinsaar
  • 3,887
  • 3
  • 15
  • 35
  • 1
    I think there's now an understanding that threads that share a virtual core must not be considered isolated. – David Schwartz Nov 30 '15 at 12:43
  • @DavidSchwartz So, unlike RAM, which is **shared but protected** via isolation of processes and virtual memory, cache is **shared but NOT protected** due to (in part) the lack of a similar **isolation of threads** sharing a virtual core? – Leo Heinsaar Nov 30 '15 at 13:04
  • 1
    Exactly. It's protected in the sense that you can't just trivially read it. But it's not protected in the sense that there are subtle ways information can be extracted from it by a clever adversary. Security-sensitive applications should not share a virtual core with an untrusted application or user, even in a different virtual machine. – David Schwartz Nov 30 '15 at 18:23
  • 1
    Sharing of L2 cache between cores provides a similar vulnerability to side-channel attacks (though L2 capacity and associativity makes such more difficult). **In theory**, even varying clock speed to take advantage of extra thermal headroom (e.g., Intel TurboBoost) could provide a source for side-channel information. –  Nov 30 '15 at 20:28
  • Ok, I see. Thanks David and Paul. From the article and your comments I'm guessing that Intel probably considered this such an esoteric exploit that it didn't bother to invest effort in resolving it for now (which may well be the right business decision). – Leo Heinsaar Nov 30 '15 at 20:40
  • @LeoHeinsaar Note that there are ways to protect the code implementing the algorithms against side channel attacks as well. Now you shouldn't just assume that any RSA implementation is suddenly well protected, but it *is* possible (to a certain extend). This is also mentioned in the paper (I can still remember it being published, such a long time ago, takes me back) – Maarten Bodewes Nov 30 '15 at 20:45
  • I'm voting to close this question as off-topic because it is about security without involving programming. Try [IT-security](http://security.stackoverflow.com) – Maarten Bodewes Nov 30 '15 at 21:16
  • 1
    [Cache Allocation Technology (CAT)](http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cache-allocation-technology-white-paper.pdf) might help. Mentioned at [Dan Luu - Why Intel Added Cache Partitioning in Broadwell](http://danluu.com/intel-cat/) – CodesInChaos Dec 29 '15 at 17:52

0 Answers0