Colin’s Very Important Knob

Thomas Ptacek | April 27th, 2006 | Filed Under: Defenses

This is funny. From FreeBSD:

Adjust dangerous-shared-cache-detection logic from “all shared data caches are dangerous” to “a shared L1 data cache is dangerous”. This is a compromise between paranoia and performance: Unlike the L1 cache, nobody has publicly demonstrated a cryptographic side channel which exploits the L2 cache — this is harder due to the larger size, lower bandwidth, and greater associativity — and prohibiting shared L2 caches turns Intel Core Duo processors into Intel Core Solo processors.

Because you almost certainly don’t yet see the humor here, let me explain.

Remember Colin Percival? I wrote about him last year. He wrote a paper, which was actually pretty good, about exploiting Hyperthreading to snoop keys across process boundaries on multiuser systems.

The refresher course on this attack:

An HT process gives the appearance of multiple execution cores without actually duplicating all the resources in the CPU. In particular:

• Each “logical processor” has its own IP and register map
• Logical processors share cache, GPRs, and execution units

Read more about HT/SMT at Ars.

Anyways, Colin noticed that “multiple threads, same cache” creates a problem. While you obviously can’t just pull another hardware thread’s data out of the L1 cache, you can get a lot of information about the offsets in memory that another thread is using, and the timing of those accesses. That’s because each time a thread accesses memory, it potentially evicts a cache line, which makes the next attempt to access the memory that used to be in the cache slower.

So Colin writes a tight loop that accesses memory offsets to probe each cache line, timing each access with the cycle counter. When the latency of one of those probes jumps, he knows the other hardware thread has hit a specific cache line. By remembering the cache lines and the order they light up, he reconstructs a cache “footprint” of the other thread. A lot of detailed low-level analysis of OpenSSL ensues, and he recovers RSA key bits.

It’s clever. It’s a real attack. And while Colin cribbed it directly from Dan Bernstein, he “extended” it to SMT and did a lot of practical work to demonstrate it against OpenSSL RSA, making him Mitnick to DJB’s RTM. Credit where due.

I’d be a Colin fan, except that Colin went on a blitz of self-promotion, picking a fight with Linus, accusing skeptics of working for Intel, and recording “vendor responses”, as if the next generation of identity thieves were chomping at the bit to get his cache graphing warez. Lost in the commotion is the simple fact that there are lots of easy timing side channels if you can run code on the same host as your target. For instance, you can run ‘ps’ in a tight loop and reconstruct ssh passwords. Of course, Colin says, the SMT attack is “qualitatively” different, because it’s much faster than any known alternative. But to a skilled attacker, the difference is one of minutes, not hours. In other words, irrelevant.

Anyways, Colin’s the FreeBSD Security Officer now. He has a blog, too!

Please don’t rush to donate money to him yet, though (even though he graciously foresook taking employment so that he could get the word out on the seriousness of his discovery!). Despite the fact that for a side-channel crypto attacker, localhost access was already gameover, Colin convinced the FreeBSD project to disable HT by default. Go FreeBSD!

The funny bit is, the FreeBSD kernel code to check and disable HT doesn’t trust the CPU’s indicator for HT. Apparently some CPUs lie about it. Instead, the HT knob checks to see if cores share caches, and uses that to infer the presence of Colin’s Very Serious Threat, and then slows the whole computer down to evade it.

Wait, that wasn’t funny. Here’s the funny bit: the Intel Core Duo has a shared L2 cache (but doesn’t share L1 caches). So Colin’s Very Important Knob (ew), well, go re-read the quote. But Colin, your paper says L2 cache attacks are “potentially interesting” too; don’t back down now, the Core Duo is evil!

Again, some context: Colin cribbed this attack from a paper that demonstrates a cache timing attack that works remote. And the likelihood that the project that Colin is security officer for is shipping code with remote code exec vulnerabilities, or kernel flaws that will allow an unprivileged process to simply dump the fucking memory from any process that dares to load up memory with something that looks like a PKCS identifier, is pretty much absolute.

Timing attacks are real. And bad. And I still predict we’re going to see them weaponized in the near future. Maybe even via shared L1 cache surveillance. But Colin made a bad call. The real effort that needs to be made to resolve the side channel problem is to pursue crypto with data-independent timing. But that’s hard, and thankless. Perversely, scrubbing extremely valuable features out of an entire architecture is neither. So guess which one happens.