Here’s the thing. I read the Meltdown and Spectre papers after getting frustrated with the hand-wavy descriptions people were writing about the vulnerabilities.

I wish I’d just read them in the first place. They aren’t that long and they aren’t that hard to follow. So I recommend developers read the original papers.

That said: after reading the papers trying to explain the issues to someone else will test your own understanding, so I don’t mean to dismiss what you’ve written.

Aside: I find “so you don’t have to” in the title to be a little off putting.

I might be wrong about any of these points. Here goes:

* I don't think Meltdown depends on eager (both-branch) speculative execution.

* Memory access during speculative execution almost has to work (and does on AMD and ARM), so that's not the problem. The problem is that permission checks on memory pages are done asynchronously on Intel, and may not abort execution until after footprints have been left in cache.

* You can't use memory writes to store the locations of transient memory reads because the instructions are transient, will never be retired, and so can't affect the architectural state (things overtly visible to programs). It's not that the CPU designers realized and specifically prevented that line of attack from working.

* It's not that cache state doesn't seem to be rolled back; it's that you can't roll it back. Modern computers are themselves small distributed systems. Changes on shared caches have to be coordinated. You'd be trading one race condition for another.

* Exception suppression isn't necessary for the attack because otherwise your process crashes. That's fine: you just run more processes. It might not be necessary to suppress exceptions at all, except that exception handling adds overhead and thus noise to your measurements. Also: the suppression technique you describe here is an oversimplification of Spectre; in reality, Meltdown deals with this with signal handlers or (probably better still) TSX.

Finally: I'd recommend not telling people to avoid the actual paper. Your summary is about as technical as Meltdown's is anyways. It's a great paper; more people should read it.

I think the specter paper stated that the CPU doesn't run both branches at the same time. Instead it picks one based on speculation and runs that branch. If it picked wrong it rolls back and only then does it start running the other branch.

The article states different. If I'm right that would also require some specter-like attack to make sure the desired branch is actually executed speculatively. Alternatively, maybe you can catch the exception and use that to indicate the desired branch was run.

Nice write up. One of our guys wrote a similar piece. https://www.carvesystems.com/blog/meltdown-spectre.html

One of the biggest challenges describing low level systems vulnerabilites like these is you have to actually learn at least a little about the CPU internals and high level explanation only gets you so far. I think adding a "why this matters" to your post is helpful.

The first section on cache timing seems off.

"The one which is being read is cached, and the exception will be raised much faster as a result."

I only read the project zero post, not the paper, but I don't recall it having anything to do with timing of exceptions. I don't see the point or relevance of this section.

Might be missing something.

Edit: mixed up Meltdown with Spectre, I'll take a closer look at this later

How easy or how likely is a meltdown attack likely to be successful against a moderately protected PC or say a VMware Cluster...these kinds of things seem hard to pin down...and if all one can do is READ - exactly what is to gain here? It seems that the machine would have already had to have been compromised in another way to get the memory that has been READ off and out of the computer system.