This doesn't make sense though. If Intel indeed plans to leave chips vulnerable except if you set a flag, then how are these bullshit patches? This will be the only solution Intel is going to deliver right? I get that he doesn't like it, but that doesn't explain why he feels lied to. If Intel says "we're going to not turn the patch on by default", wherein does he suspect the lie?
He's complaining about their "fix" being terrible, but isn't fully against using it the end since as you said, that's all there is going to be to have the chips work properly.
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")
The reasonable expectation would be that Intel fixes one (or both) of the bugs
- 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
It's not Intel's issue, it's a design flaw per se, affecting _all_ CPUs that use predictive branch execution that has effects on the processor cache, which are pretty much all processors produced in this millenium.
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.
> It's not Intel's issue, it's a design flaw per se, affecting _all_ CPUs that use predictive branch execution that has effects on the processor cache, which are pretty much all processors produced in this millenium.
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.
To be clear: I'm not knowledgeable about this at all, so I could be way off base, but my reading is that he's saying that the patches seem to be doing things that don't make sense (given the information supplied with them) - that is, Intel are trying to sneak in extra fixes or other things alongside without talking about them.
The bullshit part is that Intel is trying to push this as a 'solution'. Linux is incredibly important, so if Linus does not approve of this 'solution', it'll be very difficult for Intel to go through with it (of course, they could also be brash and still do it).
See my second message (next to yours), it's not just that, yes he thinks and clearly says that thissolution is terrible but that's not why he calls them out to be basically liars; this one is because they put useless filler garbage code all around to hide what's happening in their patches.
I think we're lucky to have someone as clear, outspoken and refusing such crap in charge of the kernel.
Part of the problem is Linus doesn't actually understand the different portions of what Intel is doing, and is mixing up IBPB and IBRS. They do different things, and he's thinking they're all part of the same thing.
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.
