CPU Caches: Threat or Menace?
Thomas Ptacek | May 18th, 2005 | Filed Under: Defenses, Uncategorized
So Colin Percival presents a paper at BSDCan (which appears to be the Usenix scene’s answer to CanSecWest in which he declares that Hyper-Threading (a processor feature that allows Intel processors to run multiple threads on the same core simultaneously, sharing functional units and caches) is basically the devil. It’s a well-written paper. I learned things from it. Percival is obviously smart. So I’m going to berate it. Here’s why:
The paper builds on previous work (the latter paper is authoritative, the former more fun to read) to point out that cache sharing can allow for side-channel attacks. Percival comes up with two conclusions:
Because cache sharing allows one thread to affect the cache of another thread programmatically (creating timing differences that are structured and can be analyzed), the cache timing effect creates a covert channel. Well, duh. Isn’t any side-channel leak a covert channels? The covert channel “insight” drives the bulk of this paper. Ok, it’s a clever (or at least, complicated) way to create a covert channel. But Percival apparently wasn’t the first to come up with this idea. And how important is the discovery of a local covert channel? Why do we think we can prevent them at all? The elimination of covert channels across a single machine involves removing all structure from any of the side effects caused by any program on the system. Good luck.
Taking that a step further, how important is the discovery of a local timing attack? The second part of Percival’s paper demonstrates how to use the cache timing channel to extract keys from OpenSSL. That’s sexy. But, as my friend Nate points out, it’s not a new threat. Typical fast crypto on an x86 processor is going to be locally timeable whether you disable HTT or not.
I have a couple problems with the way this discussion is moving.
Percival is marketing himself more than contributing to the discussion. His response to somebody questioning his change to disable HTT on FreeBSD by default? “Are you working for Intel?”. At no point since Bernstein pointed out Tromer’s paper on sci.crypt have I seen Percival acknowledge the previous work.
Today on Slashdot, Percival attacked Linus for advancing the reasonable argument that the HTT threat didn’t warrant a drastic change to default Linux configurations. “it at times like this that Linux really suffers from having a single dictator in charge…”. That’s skillful messaging, Percival; an invitation to a BSD vs. Linux debate on Slashdot. It’s also a sleazy emotional pitch.
This paper follows on the heels of a genuinely interesting timing attack result, which is that AES appears to be particularly susceptable to remote (that is, over IP networks) key extraction using the same cache timing channel. But nobody is talking about that result, because Dan Bernstein isn’t a member of the right clique to get articles posted on Slashdot.
Compared to the idea that you can extract key bytes by observing timing differences over ethernet, the idea that you can do the same trick locally seems less important. Taking that observation a step further:
Dan Bernstein (scholar hits: 376) uses his result to advance the idea that we should avoid s-box-reliant algorithms in favor of constant-time algorithms that are more resistant to timing attacks.
Colin Percival (scholor hits: 31) uses his result to advance the idea that disabling HTT by default dramatically improves resistance to timing attacks.
Problem: one of these observations is valid, but hard to act on. The other is probably invalid, but easy to act on. Guess which gets all the attention.
Like I said, I actually like this paper (and I definitely don’t pretend to be an authority on the subject matter). Mostly, it’s the crowd of hanger-ons that are pushing this issue as a clique-defining political cause that bother me.
