Run through the Linus drama filter, the only thing I get from this is "Linus doesn't like the Meltdown/Spectre patches'; Linus having issues with a patch is, well, not particularly newsworthy. Is there something more significant here than a bad first go at this?
I don't completely understand the technical issues, but reading between the lines I think the patches in question add super huge overhead. The overhead is so huge that nobody in their right mind would enable them by choice. However, the behaviour is governed by an opt-in configuration at boot time. What this means is that by default the patches will do nothing but if you opt in, you will get a huge performance hit.
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.
Particularly interesting; the opt-in creates an incentive for OS vendors to comply, as being the only platform to go all-in would create an impression to the end user of poorer performance using your product.
But are we talking about fixing it on current chips or future chips? If the former I understand Linus’ position only if there is a better solution. But if it is a hardware problem it may not. If we are talking about future chips, I thought that the fix even on 7th and 8th generations had a low overhead. Why would it have a bigger overhead in future designs?
> I thought that the fix even on 7th and 8th generations had a low overhead.
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.
To be honest, unless there is a better solution (and I don't think I heard anyone suggesting that Intel could have mitigated it in some other way in older chips), I think it makes sense to make the fix optional.
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.
What some have offered up as the ideal approach is to make the fix optional, but default to on.
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.
> See the difference between IBRS_ALL and RDCL_NO. One implies Intel will fix something. The other does not.
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.
> Linus having issues with a patch is, well, not particularly newsworthy.
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.
I also have zero criticism of Linus for his style. However to be fair, the point being made by GP is I think that if the frequency of severe patch criticism by Linus is high enough ("not newsworthy"), then the information content of all his criticisms is reduced accordingly.
David Woodhouse works for Amazon. He previously worked for Intel.
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)
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.
