My next CPU will be an AMD then.
I see where the brashness comes from. Shady dealings on Intel's part.
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.
> "boot an older os and it's vulnerable since it doesn't know to call this"
Presumably the hardware that fixes this is not even available on the market yet. How likely is it that somebody will go out of their way to install an obsolete OS version on their brand new hardware?
So not enabling this by default it's a good choice, Spectre is very difficult to exploit: so if you do critical things you enable the fix, if you use the computer for gaming, video rendering, and things where you don't care too much about security but you care about performance, you don't enable it.
The CPU can not be allowed to disable the fix, because then that could be done by an attacker. Therefore the only more secure way is to move in the secure direction, from insecure to more secure.
If for some reason you even want to forbid even privileged code from modifying the config then add an other "lock" bit that forbids subsequent reconfiguration till the next reboot.
And if an attacker can run code at the kernel level it's a non issue, as they're already on the other side of the airtight hatchway anyway [1]: they're in control of the computer and the memory.
[1]: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=...
From what I've seen. There's been demonstrated attacks using Javascript in Chrome to dump the saved passwords from the browser using these bugs
If an attack is that easy to pull off, I don't think it's reasonable to make it an "opt in"
Safari/webkit have since rolled out mitigations to prevent the attacks that they figured out but it puts the lie to the idea that Spectre is only a theoretical attack that we've yet to see an exploit for.
Proper way to fix an hardware bug like this, is that newer cpu gets protected by default, and they answer they are when queried.
So you can ask the CPU "what's your status on bug X" and the cpu answers "i'm good, you don't need to do anything" (newer fixed chips), or "i know about it but was already built, and need microcode update/special behavior to protect myself" (current chips with microcode update), "no answer / I'm not good" (old chips without update).
So new stuff is protected, and you add more protection (and slowdowns, and special stuff) for older chips that don't know how to deal with it.
What Intel is trying to do here, is to go the other way: the chips, even the new ones, will stay vulnerable by default, and when queried they say "I have a fix but I don't use it, you can enable it by asking !" and the kernel is supposed to enable it.
It's terrible for a lot of reasons, like "boot an older os and it's vulnerable since it doesn't know to call this", "additional code to enable this feature has to run for all of eternity for new chips now, instead of having to run for older chips and being phased out over time", etc ...
The reason why Intel does that seems obvious: by default the chip does not lose speed since the fix is not enabled, and so instead of "intel chips lose 30% speed over night because of a flaw" it becomes "intel adds a special security mode that protects you even more for critical applications, at the cost of some speed". Purely marketing speech and decision at the cost of proper engineering decisions, and they need and try to get OSes like Linux to play along. That's what he means by "[it] shows intel had no intention of fixing those flaws".
Additionally there seems to be a second issue in that the quality and behavior of the patches they submitted are trying to hide this deceptively simple but technically terrible behavior by making it look/sound obtuse and complicated.
In other words, intel is using its presence and weight to try and push a shitty solution, but one that is better for them marketing wise. Linus is flabbergasted to be treated like an idiot or a obedient drone that should apply such obvious abusive patches.