The only half secure way I see is to carefully pick what I install and forget running any JS code in browser, ever. Typing this in w3m/vim btw. Makes sense?

FreeBSD I am using just issued news about not being ready yet to fix this vulnerability. Fun.

https://www.FreeBSD.org/news/newsflash.html#event20180104:01

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).

https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

https://hn.algolia.com/?query=blit%20infinityplus&sort=byPop...

The parallel I see is that this is as close to anything I've ever seen in this industry to having to start so far back again. I very much suspect that we're going to be playing cat and mouse with timing attacks for the next 10 years, while pie-in-the-sky research projects just get started more-or-less today that will finally fix it.

The Mill CPU people have popped up a few times today... they seem to have an interesting opportunity here.

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.

Someone on my twitter put it this way: microkernels could see a resurgence if the cost of a context switch into kernel is just as high as the cost of context switching between 2 processes.

In all seriousness, the Nintendo Switch users a microkernel and just got completely p3wned. It's extremely fanciful that we know how to build robust modular microkernels when we can't even get the simple stuff right.

https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...

I'm not saying we should all switch, it's just that it's possible, given my understanding of how we're dealing with the intel bug, that one of the arguments against microkernels just went way. So they might make sense in places they previously didn't.

Yes, it's a form of complexity; just not what tend to relate to problems.

Seriously, completely generic IPC is not something impossible. You may have some to create some large drivers, but the insulation is still there, even for those.

For example, Haiku most probably won't get around to implement KPTI any time soon. But then again, most people consider it more of a fun/hobby OS[0] anyway, so it wouldn't matter that much.

[0] And that isn't meant negatively at all, I actually think the computing landscape would be way more fun again if there were many more projects like it again. Not every OS needs to try and be an everything-OS, and not every OS needs to follow the "always online, everything through the internet" paradigm. If the most interesting use-cases are entirely offline, most of today's popular attack vectors cease to exist.

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

Seriously at least no more JS running free in browser makes me happy on so many levels.

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

RISC-V is OoO, isn't it?

i don't know riscv arch but I've seen it mentionned in spectre paper so that's probably the case

My money is on more x86 procs with more cores, and even flakier cache coherency and memory protection.

I wish I knew how to interpret this comment. Did he manage to output his own firefox memory using client side javascript? Or perhaps a local script running in terminal? or is it totally different and hes describing running a process on his own webhost that broke the vm container and printed out other hosted websites ip addresses?

The Spectre paper outlines that this is not only possible to do in javascript, but they included a Proof-of-concept of it working in javascript to read anything from that process's memory.

And while that alone might seem pretty innocuous, think of things that are kept in memory for a specific tab. This could make XSS attacks able to grab HTTP-Only cookies, or be able to read some autofill data or potentially password autofill information. I don't know enough about the architecture of those things to know if they are kept in the same process, but if they are it's possible.

That being said, I didn't read any specific reason why that JavaScript PoC couldn't be expanded to work on other processes just like the rest of the Spectre attack. And personally I'm assuming it's only a matter of time before it is figured out.

You can enable (experimental) Chrome process separation here:

chrome://flags/#enable-site-per-process

upper window is firefox

https://twitter.com/misc0110/status/948869631313399809

That is, the process tried to read some data from protected memory A and did some fancy stuff with it such that left enough breadcrumbs that after the CPU responds to the illegal read, the process still has enough info to piece together what was in A, at least from timing of reads, right?

Why not kill the process instantly on a prohibited read, then? Do these prohibited reads happen too often to switch from "oh, that's okay, you can try again and do other stuff" to "the punishment is death"?

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.

But not only that, the entire illegal operation can be fenced behind a speculative execution with a simple "if" branch. And illegal reads happen in that kind of context all the time because (for example) that's how every FOR loop ends.

There's really two places where pipelining and speculative execution are causing this problem - the obvious one where the CPU is allowed to manipulate protected data before everything gets blown away (except cache loads of legal data, hence the problem), but a second one that means that reads of protected data happen all the time in normal branch prediction misses.

When it happens in normal flow, you can't punish it by killing the process. Reading protected memory in a speculative branch isn't some digital "attempted breaking an entering" that you can clamp down hard on, it's totally normal behavior.

I get it now, thanks.

> [...]

> 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.

>other than the flaw that leaks information,

But that flaw is pretty hard or impossible to detect.

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

That is very impressive.

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.

What's new here is exploitation of speculative execution (branch prediction). It takes what was already difficult in the world of crypto to a new level of difficulty (or maybe not; it looks like the fix for this will be to effectively disable branch prediction in sensitive code, or even preferably by default and enable it only where it's necessary and safe).

How is that a security issue? It's in the same process.

Could the subroutine troll through memory and find it? Yes, but it would be orders of magnitude harder than having that pointer in a register.

Better example is if you are using 64 bit ints in registers as security tokens. Those should be zeroed after use and the compiler needs to not accidentally optimize away zeroing them.

I don't quite see how an attacker would take advantage of this is a real-world scenario.

Could probably reproduce from upstream Yocto distro and the free version of Qt.

Much larger attack surfaces to worry about like their craptastic security around USBs that farmers stick in to read maps.

I guess this is why Intel can get away with it. Nobody cares.

NPR did run a meditation story this morning too,

https://www.npr.org/sections/health-shots/2018/01/04/5751679...

So I'm failing to see how it's wrong. Are you going to put off a purchase because of Meltdown? Are you going to do anything beyond complain for a few threads on HN, apply kenrel patches, and go back to business as usual? Are any of your actions going to cost Intel in any significant way?

I did at least disable javascript in my browser. That's probably more than what most have done so far.

I guess this is why Intel can get away with it. Nobody cares.