[krylon]

> by the way, that PoC was intense. Makes you wonder if the NSA knew about it all along :)

Colin Percival found a very similar issue with Intel's implementation of SMT on the Pentium 4 in 2005: http://www.daemonology.net/papers/htt.pdf

So the general idea of using timing attacks against the cache to leak memory has been known for at least that long.

In 2016, two researchers from the University of Graz gave a talk at the 33C3, where they showed that they had managed to use that technique to establish a covert channel between VMs running on the same physical host. They even managed to run ssh over than channel. https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wron...

In light of that, I would be surprised if the NSA had not known about this.

[tptacek]

Can I put a plug in again for how fucking cool the Meltdown and Spectre attacks are? They're much more interesting than just cache timing, which as you note have been well-known for at least a decade (and much earlier in the covert channel literature).

Unlike "vanilla" cache-timing attacks:

* Meltdown and Spectre involve transient instructions, instructions that from the perspective of the ISA never actually run.

* Spectre v1 undermines the entire concept of a bounds check; pre-Spectre, virtually every program that runs on a computer is riddled with buffer overreads. It's about as big a revelation as Lopatic's HPUX stack overflow was in 1995. There might not be a clean fix! Load fences after ever bounds check?

* Spectre v2 goes even further than that, and allows attackers to literally pick the locations target programs will execute from. Try to get your head around that: we pay tens of thousands of dollars for vulnerabilities that allow us to return to arbitrary program locations, and Spectre's branch target injection technique lets us use the hardware to, in some sense, do that to any program. And look at the fix to that: retpolines? Compilers can't directly emit indirect jumps anymore?

It's good that we're all recognizing how big a problem cache timing is. It was for sure not taken as seriously as it should have been outside of a subset of cryptographers. But Meltdown and Spectre are not simply cache timing vulnerabilities; they're a re-imagining of what you can do to a modern ISA by targeting the microarchitecture.

[krylon]

> Can I put a plug in again for how fucking cool the Meltdown and Spectre attacks are?

Yes, you can! :)

I get your point. From the perspective of somebody who normally does not deal with such low-level affairs, the difference to prior cache timing attacks is not /that/ obvious. It all looks like black magic to me, even after I roughly understand how it works.

[_wmd]

There's no reason to invent new terminology for speculative execution. Also, the mapping between the variety of CPU caches and real memory has been known imperfect since the beginning of time.

But meanwhile, yes, can definitely agree how fucking cool it all is

[tptacek]

What new terminology got invented?

[_wmd]

Perhaps I've been living under a rock for the past 30 years, but transient instructions are a new idea for me

[tptacek]

What's the "old" term for speculated instructions that aren't retired?

[mehrdadn]

I've never heard of a term for them but I would find "speculated instructions" clear enough in context.

[chx]

> In light of that, I would be surprised if the NSA had not known about this.

Call me a tinfoil hat conspiracist but the only rational explanation I can find of IBM POWER and z CPUs still vulnerable to Spectre is the NSA forcing IBM not to fix it. I read somewhere that the z196 had three magnitudes more validation routines than the Intel Core at that time. It's extremely hard to believe they haven't caught this.

[warkdarrior]

Cache timing attacks have been known for a while, for example across VMs in 2009: https://cseweb.ucsd.edu/~hovav/dist/cloudsec.pdf

[ckastner]

This paper from 2005 describes a cache timing attack that enabled an unprivileged process to another process' AES key:

https://www.cs.tau.ac.il/~tromer/papers/cache.pdf

IIRC, the only way to address the issue was the addition of the AES-NI instruction set, which came a few years later.

[cesarb]

> IIRC, the only way to address the issue was the addition of the AES-NI instruction set, which came a few years later.

Another option would be to use a bitsliced implementation of AES, at some cost in speed. I could also imagine an implementation which read the whole table every time, using constant-time operations to select the desired element(s), but I don't know how slow that would be.