A collection of Meltdown/Spectre postings

Ah yes, now I see. I had forgotten about that link since I successfully looked at it earlier, which means that it was open access for a while, with luck, perhaps Red Hat will restore access soon.

jake

I don't think so. My problem is more in understanding of what is going on.

Confusingly, there are two closely related issues, which have named Spectre and Meltdown. Spectre boils down to this: if you can make a process execute a very specific sequence of instructions another process can "read" it's memory using a cache timing. The demo program tries to show it in action, but since forcing a program to execute a series of instructions it didn't intend to is a tad difficult it a demonstrates a process reading it's own memory without, err, actually reading it. It's the reading memory without asking the CPU to execute any instructions that actually read it that's generating the ooooh's and aaah's here, as obviously reading your own memory by asking the CPU to do it for you is rather common place. Nonetheless it does causes problems for programs like web browsers that assume a JavaScript code can only access memory the browser allows it to read. Now it's come to light random JavaScript can bypass those control's and access anything in the browsers memory it damned well pleases, I'm sure there is much hair pulling going on. That aside, if you can make a program execute arbitrary code, you've got much bigger problems that cache timing attacks. Which is good, because (a) every CPU that speculatively executes more than a couple of instructions is vulnerable to this and (b) there is no hardware fix.

The second issue is called Meltdown. This is the one that apparently caused the Intel CEO to sell as much of his Intel stock as the company allowed. It appears that rather than first checking if you are allowed to access memory then fetching it only if you are allowed to do so, Intel CPU's execute the two operations in parallel to speed things up. So the fetch always happens and the data ends up in cache - it is only the final step of passing the data to the program that fails. This means you could then probe what the data was by doing memory fetches, and using timing to detect whether it came from cache or not. Or you could if it weren't for that fact that a program doing an invalid memory access fails in a fairly spectacular way, a way that destroys the cache foot print you are look for. I thought you could bypass that by ensuring the instructions were executed speculatively, which means the Spectre demo program would have been able to read kernel memory - but apparently not. The paper says they use a more convoluted method involving side effects of transactional memory, however they also imply that just a speeds things up. I'm not sure what the exact trigger is, but whatever it is, only Intel has it. I find that remarkable given I was reading papers 20 years ago on the speed ups that could be obtained by doing memory fetches and permission checks in parallel. Fortunately there is a simple software fix: don't put the kernel in the user processes page table. Sadly this slows things down a little, because now the kernel has give itself access on every syscall.