[Valmar]

> In a related development, there are proposed patches to the Linux kernel (not yet merged) to blacklist the broken microcode updates

Linus probably won't pull it until it's truly known to be stable, because of his attitude towards having decent quality code and not causing needless system instability.

Without Linus... who knows what would have happened by now.

[cesarb]

They are on the "tip" tree (https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...), so they'll probably be sent to Linus as soon as the merge window opens (Linux 4.15 has just been released, so the merge window should open soon). I expect these patches to be on 4.16, and also to be backported to the stable releases (4.15.x and others).

But yeah, upstream Linux kernel development is taking it slow. As far as I can see, variant 3 mitigations (PTI) are already in, variant 2 mitigations are partially in (retpoline) and partially not (the microcode dependent ones), and variant 1 mitigations are still under discussion.

[jerf]

"But yeah, upstream Linux kernel development is taking it slow."

Taking it slow seems very appropriate to me. This seems to me to have been a case of everybody grossly overestimating the short-term portion of the catastrophe, and underestimating the long term.

In the short term, the only people who were going to be plausibly affected in the next three to six months are people on shared hosting of some sort where you may share a server with somebody else's untrusted code, where an accelerated fix is in order, but also something that can be centrally handled. I'm not that worried in the next three to six months that my personal desktop is somehow going to be compromised by either Meltdown or Spectre, and personally, if I see a noticeable performance issue I may well revert the fixes (I'm on Linux), because first you have to penetrate my defenses to deliver anything anyhow, then you have to be in a situation where you're not going to just use a root exploit, which probably means you're in a sandbox or something which means it's that much more difficult to figure out how to exploit this. For most users, uses, and systems, spectre and meltdown aren't that immediately pressing.

Meanwhile, in the long term this may require basically redesigning CPUs to a very significant degree; there is no software patch that can fix the underlying issues. It is difficult to overstate the long term impact of this class of bugs. IMHO the real problem from the jousting match with Linus and Intel last week isn't that Intel's patches today aren't quality code, but that it makes me concerned that they're just going to sweep this fundamental problem under the rug. As I said in another post on HN, I fully understand that remediating this is going to be years, and I don't expect Intel to have an answer overnight, or a full solution in their next "tock". But if they're not taking this seriously, we have a very large long-term problem. We're only going to see more leaks in the long term.

[Mister_Snuggles]

I read somewhere that people have developed POCs of these using JavaScript. At minimum, you'll want to keep your browser up to date as there are mitigations happening there too. Who knew that exposing high precision timers to untrusted JavaScript would be a bad idea?

Apart from browsers, it's fortunately pretty easy to avoid running code you don't trust on your devices.

[jerf]

What I've seen that the POCs can actually do is not worth running around with your hair on fire, from what I've seen.

Note I did not say there is no reason to be concerned about Meltdown and Spectre... just that for most users, uses, and systems, it's not that important. In the next three-to-six months, if you care about security at all, unless you are already running a tip-top tight operation, your money and effort is better spent defending against the many already-realistic threats, rather than worrying about the vector that may someday be converted into a realistic threat. Meltdown isn't what is going to drag your business to a halt next week; it's that ransomware that one of your less-savvy employees opened while mapped to the unbacked-up world-writable corporate share that has all the spreadsheets your business runs on. At the moment, the net risk of applying the Meltdown fix comfortably exceeds by several orders of magnitude the risk that Meltdown itself poses.

And my point is precisely that for most users and uses, that panic was not justified. Those for whom that is not true (VM hosting companies) already know they need to be more aggressive. There was no point in pushing out patches that nearly bricked some computers.

[Mister_Snuggles]

I agree with your points. In fact, I made the same argument about removing a Heartbleed/Spectre-related patch that caused issues for one of our applications - "the machine doesn't execute any untrusted code, so this patch isn't strictly necessary."

[cesarb]

Update: the merge window has started, and that blacklist has just been merged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[speedie]

Everyone would have politely installed their "fixes" . This situation shows why linus was swearing .

[Valmar]

Exactly. He's very intelligent about how he manages the kernel, which is precisely why it is preferred by a majority of businesses throughout the world, and is the absolute #1 in the supercomputer world, for the top 500:

https://www.top500.org/statistics/details/osfam/1

[speedie]

I was just pointing out why politeness gets you nowhere when dealing with eejits . Linus improved that Capone's saying about kind word and a gun .