The reason he refuses those current patches and directly call it a lie/deception is because of what my last two paragraphs related; if you read his message (where the link points to) it's about half way: Intel tries to disguise it by doing it in a convoluted way. Basically they try to avoid making it obvious when looking at the code, because they don't want a "if (intel_chip) enable_fix_because_default_is_broken_on_intel();" and instead pushes something that looks like the kernel needs to do lots of complex stuff [aka, "it's complex, and a fix-on-chip is not enough the kernel needs protection anyway !", and that means a terrible patch with lots of garbage and filler code.
Intel's intention is clear in that they specifically pushes this in the same patchset as the "tell the chip to be secure", trying to mush the two things together to make it looks like it's all the same thing, whereas in reality it should be two patchset: one to enable the security mode, and bad for intel marketing wise. And a second one to add those "fixes" to the kernel, that would be refused because terrible and in part unecessary since retpoline already protects it. What Linus is saying is "sure I need the first change, but since you're intent on pushing them together I'm refusing them, because the second one is pure garbage, and you mix them together to hide the first".
Eg quotes from said mail to show it's indeed his problem:
> So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint.
and
> The patches do things like add the garbage MSR writes to the kernel entry/exit points. That's insane. That says "we're trying to protect the kernel". We already have retpoline there, with less overhead.
(what he means here is that they try in their patch to make it look like the kernel needs a special protection, while it already has it through retpoline)
and
> So somebody isn't telling the truth here. Somebody is pushing complete garbage for unclear reasons. Sorry for having to point that out. If this was about flushing the BTB at actual context switches between different users, I'd believe you. But that's not at all what the patches do.
(eg "why are you pushing all this crap around to hide what's really happening/need to be executed")
- In newer CPU's. There should be mitigations against these attacks. That would probably seriously hurt intel by delaying their future processor launches
- In Older/existing CPU's through microcode updates. Bar literally making "fixed" versions of every Intel CPU in the last 10~ years. This is the only way to resolve the issue on existing hardware
Instead of doing that. Intel wants to avoid the much-reported "30% performance hit" by simply saying "Well if you want this FEATURE, you can enable it in your OS!"
Intel is trying to downplay a massive security vulnerability in their hardware as something that OS vendors can just let users opt in/out of
That said, there _might_ be a solution to this problem in a way that predictive branch execution does not need to be removed completely from future architecture, which would be a thing we don't really want to loose, even if it increases safety. During that time, it makes sense to disable it, but not by default. The only implication is that older systems must be patched, which is every admin's responsibility.
Just because other CPUs have this flaw, doesn't mean this isn't Intel's issue. Regardless of the state of other CPU manufacturers, Intel is producing buggy CPUs.
Is there a simple table of every mainstream purchasable CPU out-there and whether it was affected?
I think we're lucky to have someone as clear, outspoken and refusing such crap in charge of the kernel.
This could be a sign that these things are poorly written and need to be refactored into something more obvious, or it could be that they're so fundamentally complex that it's going to be difficult to grasp without context.
If it is that fundamentally complex, then it sounds like they need to find a better solution.
Hopefully the goal here is to get everything to a secure state, with time to iterate and improve once everyone can sit back and breathe. Hopefully.