Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown:

A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room.

An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of non-restricted books and go into the restricted room. Depending on what they read in there they rearrange the pile of non-restricted books into a particular order. A guard comes along and sees them, they are thrown out of the restricted room and their pile of non-restricted books is put on the issue desk ready to be put back into circulation.

Their conspirator looks at the order of the books on the issue desk and decodes a piece of information about the book in the restricted room. They repeat this process about 500000 times a second until they have transcribed the secret book.

I don't understand this explanation :/ Why is the room considered restricted if you can go inside? Do I know how all books that exist in the library? How does the order of the thrown out books pertain to the secret book?

> Why is the room considered restricted if you can go inside?

That's the bug. The guard only checks to see whether you're supposed to have access after you walk in and start (speculatively) rearranging books. One way to fix this bug would be to have the guard check your access at the door.

What is the analogy behind being able to go into the restricted room?

The restricted room is the part of the machine behind the protection. Memory reads are not checked at the tine access. They are checked when the instruction retires.

On intel* this isn’t a property intrinsic to superscalar processors, other architectures check it in flight or while it’s in the issue queue, preventing this side channel.

You can call into the kernel.

edit: s/call into/trigger a syscall/

You don't even need to do that for meltdown.

I don't understand how this info can be used for getting what was inside the book? If my understanding of your explanation is correct, book name is analogous to memory address. When the victim (legit process) returned the book with name X (called free on the mem block X), the librarian (OS) erased all pages of the book and repurposed it for printing another book before handing it out to the evil dude(snoopy process).

My attempt, assuming that the books only contain one character each:

The librarian has a list of books you're not allowed to take out. You request one of those books (book X), but it takes a while for search to run to see whether you're allowed to or not. While you're waiting, you say "actually, I'm not really interested in taking out book X, but if the content of that book is 'a', I'd like to take out book Y. If the content of that book is 'b', I'd like to take out book Y+1, and so on".

The librarian is still waiting for the search to complete to see if you can take out book X, but doesn't have anything better to do, so looks inside it, sees that the letter is 'b', and goes and gets book Y+1 so she can hand it over to you.

Now, the original check to see if you can take the first book out completes, and the librarian says "I'm sorry, I can't let you have book X, and I can't give you the book I fetched that you are allowed to take out, otherwise you'd know the content of the forbidden book."

Now, you request book 'Y', which you are allowed. The librarian goes away for a few minutes, and returns with book 'Y', and hands it over to you. You request book 'Y+1', and she hands it over immediately. You request book 'Y+2', and she goes away for a few minutes again, and hands it over.

You now know that Y+1 was (probably) the book she fetched when you made the forbidden request, and therefore that the letter inside the forbidden book was 'b'.

Great explanation - thank you. One thing I don’t understand is how this can be exploited from javascript. Does it have timing primitives so fine it can tell the difference between a memory lookup served from memory va from cache?

Yes it does because javascript execution has had to become very fast. Fast means you can run a very tight loop that updates a counter to create a fairly high-resolution clock.

What I don't understand is how the branch predictor is even exploitable from JavaScript -- it doesn't have pointers. How can it "request" arbitrary memory locations and time the results?

It has byte arrays and indexing on those which is equivalent to having pointers. See page 6 and 7 of the Spectre paper.

So the mid-term fix for js jits should be to gimp indexed array access to the point where an out of bounds index value can never enter speculative execution, right? I'm no expert in these low-level things, but I imagine that speculative execution happens only from conditional jumps and that alternative bounds assurances (e.g. using base+idx%len as the eventually address or limiting it to a sandbox-owned region using a few bitmasks) should be possible that reliably stall the pipeline without allowing speculative access (obviously at considerable performance cost, but the jit should be able to whitelist certain safe access patterns and/or trusted code sources to not let this get out of hand). Am I missing something?

I believe they made their own "good enough" clock out of a loop in a webworker.

Thanks, this was a great explanation, really simplified it!

I understood with your explanation, thanks!

The person checking out the book is a program, so they aren't the brightest.

They check out the book called "how to go to facebook.com". Then they check out "how to type a password". Then they check out "Typing '1234' for Dummies".

I bet you'll never figure out how to get into their facebook account.

Fantastic explanation of cache timing attacks. This morning I was explaining spectre to non-technical people and let me tell you, "leaking L1 CPU cache memory," is a real party starter. So I'm using there librarian example going forward.

I used your explanation in a longer note, "Spectre: How do side-channel attacks work?"[^1] to try and explain how side-channel attacks work (partly to myself, and partly to non-hackers).

[^note]: https://www.facebook.com/notes/petrus-theron/spectre-how-do-...

Thanks for the heads up!

Thank you for this. Would you say this applies to both Spectre and Meltdown, or one and not the other?

This is a general explanation of side channel attacks, as I understand.

yeah, I don't think it is a perfect analogy for Meltdown, I'll try one, someone correct me if I'm misunderstanding Meltdown.

Let's say you want to know if your boss is away on vacation next week so you call their admin and say "you need to double-check my contact info if the boss is going to be out next week". They load up the boss' calendar to check and based on his presence next week then load up your info. Only once done, do they take the time to remember the boss didn't want you to know wether they are in or out. So you hear back, "sorry, can't tell you that, but you follow up with "OK, well can you still double check that my phone number is..."

If they respond quickly with a yes, then your file is still on their screen and the boss is in fact out next week. If there is a short pause while they look it up, then the opposite.

A timing attack is one type of side channel attack. These types of timing attacks can also be used against poor/unsuitable crypto functions, or even some processes involving general computation e.g. If it takes longer to reject input A than input B, you can reason that input A is closer to the answer (similar to someone reading a paragraph until they reach the first error).

Other side-channel attacks can come in the form of analysing network data, power-consumption (CPUs use more power when they are "busier")... even noise (listen for when the fans start spinning up).

Is blinding the only real solution to most of these attacks against Crypto?

Yes, this is a general explanation of side channel attacks against some kind of caching. The more specific example tries to be closer to the type of situation that happens in Spectre, but it is not a direct analogy.