The end result is that Intel can say, "We've fixed the security holes". Linus can apply the patches and say, "I've fixed the security hole". However no distribution will enable it because they will suffer from a massive performance penalty if they do. The end result is that the security hole will remain, but the average person/manager/etc will not be aware of it.
As far as I can tell Linus is calling that out as being complete BS. From what I can tell, his reasoning is that if there needs to be a performance hit, then Intel can eat it. They will have to get their act together and fix the problem in upcoming processors or else basically nobody will buy them. The implication is that Intel has no intention of fixing the problem in the next generation of processors and is hoping to sweep it all under the rug -- they have a fix. It's not their fault if nobody enables it.
The situation is a bit delicate because if Linus forces the Intel processors to be slow, then Intel will blame him -- their patches are only slow if you opt in to some completely-not-understandable-kernel-patch-option. He's basically refusing to play ball at all -- which is probably the correct stance (assuming I understand what's going on -- insert disclaimer about being a random person from the internet here).
I don't think Linus is necessarily blaming anyone in particular. That's why he says the reasons behind the patches are unclear. I think he's hoping that causing bad publicity will get Intel to abandon their tactic of being politically careful. Getting slagged of by Linus carries a certain stigma and Intel may consider it prudent to offer up information more quickly in order to stem the damage.
One of the fixes slow down kernel syscalls by a significant amount. So much so that your IO will be heavily affected. Intel is mostly responding is dishonest ways, e.g. showing the impact on CPU-only benchmarks.
The current patches do have a significant impact!
What someone else explained here is that due to the heavy impact, it seems Intel isn't planning to fix it in future CPU's. Basically a "if you are super security minded enable that special slow secure mode Linux has where they slow down your performance". Meaning, blame Linux/your requirements not Intel.
The vulnerability as I understand it doesn't affect everyone in the same way. Save for the javascript vector which can be easily mitigated (and will be), most consumers and single tenant servers aren't really affected (if you have rogue code executing in user mode, access to kernel memory is the least of your worries, it will have encrypted your data and made your device a spam or DDOS bot before). The risk is really in a large organisation where you need to be resilient to one machine going bad, and in a multi-tenant infrastructure (cloud / hosting providers).
I don't really get the blame game that seems to be at stake here.
There might be some level of concern for the consequences of adding to the patch-maintenance load of technical organizations. Already, IT groups and application maintainers cannot always be fully relied upon to have their machine fleets and libraries up to date.
It's also possible that an unpatched machine might suffer from some risk in the form of a significant privilege escalation vulnerability here. Some might opine that any such vulnerability should be closed off wherever possible, as there may be other threats than cryptolockers or botnetting.
I think that's a pretty interesting claim on his part. I can't weigh in too much on the evidence to support this claim, but it's certainly more than just a rant it seems.
Why not? The lead engineer of the linux kernel project has specific issues with security patches from a major hardware vendor.
I understand the constant distaste that some users here have with Linus' style, but I don't understand the constant need to denigrate his positions by attempting to paint them as particularly diminutive.
It is a series of patches from engineers at both Intel and Amazon. Linus was replying to an in progress discussion where people that are working on the patches are discussing things.
There's some disagreement between the people working on the patch series (which is what Linus jumped into), but Linus also seems to be misunderstanding some fundamental things about the nature of the patches to begin with. (Reading the rest of the thread is more informative, but less entertaining, than just the bit with Linus yelling about things)
Instead, they do some crazy crazy black magic in the patches.
Intel will make a fix but the fix will be disabled by default as that results in the best performance numbers, those that will be reported in the media.
When you want to use the CPU in the cloud, you have to enable the fix and get much lower performance. But nobody in the media will care about that as they have the nice performance numbers and therefore Intel don't care to implement a fix with high performance.
Seems like Intel just wants to half-arse a solution.