How a researcher hacked his own computer and found 'worst' chip flaw

Which is really sequel to the short story: http://www.infinityplus.co.uk/stories/blit.htm , and which is followed up with http://www.lightspeedmagazine.com/fiction/different-kinds-of... (the "FAQ" I linked above is in between those two things).

As for Javascript: I use uMatrix in Firefox, with a default rule that disables all JS unless I explicitly have whitelisted it for a certain domain. Some websites break and don't show content. I intend to just skip those websites.

The reason I set this up was actually to prevent tracking, but now it seems that it's good security practice too...

The web is getting more and more annoying anyway, and I waste way too much time with it, so reducing my reliance on it seems like a good idea in any case.

> This could be an extinction level event for less popular OSes. Intel, and to a lesser extent AMD, may end up causing enormous damage for which they'll pay nothing much.

It's parsing untrusted data using C. It's not secure because it renders to a terminal!

in order instead of out of order, more trivial parallelism..

upper window is firefox

Because it may not be known whether or not the read will have ended up being prohibited at the time it's speculatively executed. Think of a simple for loop over the contents of an array: usually at the end of each loop iteration you jump back to the beginning of the loop, until the last time you don't, when i > array.length or whatever. The branch predictor will likely predict that the last time you'll jump back again (you always have before, and it doesn't know the actual value of array.length yet since that takes hundreds of cycles to come back from memory) and try to speculatively execute the contents of the loop body on what turns out to be out-of-bounds data. That's not typically malicious; it's at the end of pretty much every iteration over an array ever.

So then, if we can reliably get our loop to operate on a bit of data that might turn out to be out of bounds, the trick is then to have a loop body like this:

if (potentially_illegal_bit == 1) { load_legal_location_1() } else { load_legal_location_2() }

After the branch misprediction occurs, the state of the program gets rolled back so we don't know what potentially_illegal_bit itself was anymore, but we don't have to, we can surmise it from the cache contents. The program isn't going to do an illegal read, it's going to do a legal one, to either legal location 1 or legal location 2, and see which is faster (as only one of them should be cached). Both reads are legal and will succeed, so the only difference is the speed. We've now exfiltrated one bit of data from outside of your array bounds, but the only actually illegal read was speculative, which, as far as the CPU is concerned, is par for the course (predictions are wrong all the time), so no harm, no foul.

> [...]

> Why not kill the process instantly on a prohibited read, then?

Because it was the CPU that tried, not the process/software that tried. It only tried in a branch that wasn't ever to be taken. Say for instance you have a pointer to some memory and a flag telling whether it is an absolute pointer or a relative pointer. Your executable checks the flag and sees that it is an abosolute pointer, so it reads the memory at the address. But the 'else' statement that was never supposed to run speculatively runs and treats the pointer as a relative offset that just randomly happens to go into system memory.

You can't kill the process because of this, because the program never actually tried to go into system memory, the CPU just speculatively tried, and speculated wrong.

    if (has_privileges) {
        // Access protected memory
    } else {
        // Do something else
    }

It's an interesting question. The pedantic answer is that they technically do actually happen all the time, that's just a page-fault. However in the page-fault handler you could just check what address they were looking at (And we already do, since we have to decide if we need to map a page, or throw a SIGSEGV), so effectively you could block them by checking the address.

But it's actually fundamentally a lot worse. On its own, meltdown might be preventable that way, but you can combine meltdown with similar patterns to the spectre exploit to achieve the meltdown exploit without raising the exception. The kernel then can't prevent this, because no exception is raised, so it doesn't actually know anything happened.

csirac2's list on reddit: https://www.reddit.com/r/securityengineering/comments/7o2uzy...

Original paper (which I actually read when it first came out earlier this year): http://www.cs.binghamton.edu/~dima/micro16.pdf

First PoC for leaking ASLR based on timing side-channel attack: https://github.com/felixwilhelm/mario_baslr

I've been trying to wrap my head around for over a decade how these side channel attacks between L1 caches and branch prediction caches don't happen.

Wish I had published my November 2016 research into function call leaks. CPU registers leaking information between function calls is still a huge unmitigated issue.

You want to shit yourself, goose GCC or LLVM to instrument your function calls with a dump of everything in CPU registers before they start. Do this with libraries that people blindly link in dynamically.