This is how Meltdown works

Isaac Lyman - Jan 5 '18 - - Dev Community

Meltdown and Spectre are the two latest exploits throwing the tech world for a loop. They have a lot in common with each other; both depend on built-in features of your computer's processor.

After doing some reading, I think I understand the Meltdown exploit well enough to explain it in layman's terms. If any of this is incorrect, please comment below and correct me.

As you know, the CPU (or processor) is the brain of the computer. It performs lots of simple instructions very quickly, like adding numbers together and reading memory.

Suppose your CPU is an employee at a fast-food counter. People line up in front of the counter and order items off the menu, then pay with their credit card, then go to the pickup line and get their food. The process is very simple. If they don't pay, they don't get their food.

(Similarly, the CPU accepts instructions from a process, makes sure the process has the permissions necessary to execute those instructions, then executes them and returns the results to the process.)

The fast-food place prides itself on FAST service. In fact, it will lose a lot of customers if any other restaurant is faster than it. So it starts taking shortcuts. For example, as soon as you tell the cashier what food you want, they send your order to the back and the cooks start making it, even before you hand over your credit card. They cook it and put it on a tray in the back, ready to deliver to you when you get to the pickup line. This speeds things up a lot. Of course, if you can't pay, they have to cancel the order and throw away the food, which is a waste. But most people pay right away, so it's not a big problem, and the gained efficiency of getting started sooner definitely makes up for it.

(Your CPU does this. It executes certain instructions while it's checking the process's permissions, and doing these in parallel (called "speculative execution") saves it some time. If it doesn't have the correct permissions, it cancels the instructions and dumps the results.)

Then the restaurant gets a bright idea: if you don't pay, instead of dumping the food, they'll leave it on its tray in the back for up to 5 minutes. If someone else puts in the same order before the 5 minutes are up, they'll give them the food from your cancelled order. Less food waste, quicker service. Win-win.

(Your CPU does this too. It has its own cache where it puts the results of executed instructions, before it even knows if the process has the right permissions.)

One day, the restaurant comes up with an incredible innovation: the ability to copy food digitally. Once the food is made, it can be given to several customers at a time without re-making it from scratch: just copy it onto each customer's tray. The R&D department hasn't figured out how to keep the food hot and fresh for longer than 5 minutes, but if one customer orders a #6 combo, everyone else who orders a #6 combo within the next 5 minutes will get a copy of the same meal, and they'll be able to get it super quick, since it doesn't have to be made from scratch. It's super efficient. Profits are soaring.

(I know the metaphor is getting thin at this point, but that's how data works. Once the CPU has something in the cache, it can hand it out to as many processes as needed until that part of the cache gets overwritten or dumped.)

The restaurant's final innovation is all about privacy. Ever been too embarrassed to ask for three large orders of fries, all for yourself? Worry no more: thanks to a very creative system of white-noise machines, thick curtains, and whispers, you're now able to order and eat your food without any other customer knowing what you've got.

(Private communication between a process and a CPU is very important. It prevents programs from spying on each other. You wouldn't want your Solitaire game to be reading your Outlook password, would you?)

You're a fast-food hacker, and you want to figure out how to manipulate the restaurant in order to find out what someone else has ordered. You dedicate a lot of time and thought to this.

First, you discover that if you order food that's already been made in the last 5 minutes, you get it a lot faster than if they have to make it fresh for you. So by using a stopwatch, you can determine whether it's been ordered by someone else recently. In fact, if you keep an eye on the counter, you can tell whether your order is made fresh or just digitally copied, even if your credit card gets declined.

(The point of the CPU cache is to speed things up. If instruction results are needed multiple times, getting them from the cache is much faster than crunching the same operations over again. And even if a process doesn't have the right permissions, it can ask the CPU for some data, time the interaction, and find out whether that data is in the CPU cache or not.)

From this you hatch your plan. You go to the restaurant and pick a victim: another customer who's already eating, and you want to find out what they ordered. You approach the cashier, claim to be that other customer, and ask if you can modify your order. You say you accidentally ordered the menu item previous to the one you wanted; can they please change your order to the next menu item? Out of courtesy, they say yes and send the order to the kitchen, but ask to see your credit card to verify your identity. When it turns out that you're lying about being the other customer, the cashier cancels the order -- but it's already been cooked; it's on a tray in the back. At this point, all you have to do is order each item on the menu, one at a time, stopwatch in hand, until one of them comes back fast enough to indicate that it was already made. And then you know: the other customer ordered the menu item previous to that one. For example, if #6 comes back very quickly, you know the other customer ordered a #5.

(CPUs can be instructed to look up data based on other data (for example, "look up the memory address 0xFFF; it contains another memory address; return the data stored at that memory address"). This is the final piece of the puzzle. Meltdown asks the CPU to look up a piece of data based on other data it doesn't have access to. The CPU rejects the request, but it still does the calculation and puts the second piece of data in its cache. Then Meltdown just needs to request a bunch of memory addresses, and whichever one comes back really fast is the other part of the equation (in our example, it's the memory address that was stored in the original, forbidden memory address.) This allows Meltdown to read anything in memory. This is very bad.)

That's Meltdown. And you are affected by it. And you should update your browsers and your OS immediately to get the patch.

In retrospect, maybe this would have been easier to explain without the fast-food metaphor...but hey, I had fun.

Let me know if this didn't make sense to you, or if you've got anything to add.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player