I'm going to be honest, I need an ELI5 here. I know what the meltdown/spectre issues are, and kinda understand what retpoline is.
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.
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.
https://support.google.com/faqs/answer/7625886
“Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches.
The name “retpoline” is a portmanteau of “return” and “trampoline.” It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.
He is still ofcourse mad that they don't seem like they want to fix Spectre correctly but that seems tangential to how pissed he is that they are trying to get code merged that clearly does something other than just mitigate Spectre.
Unfortunately this entire thread is derailed with garbage about how Linus talks, rather than the fact he thinks Intel is doing something really fucking dodgy here and we should all try work out what it is.
1) Recent patch submissions imply that Intel has no good hardware or microcode mitigation for spectre-like attacks. There is a sub-complaint that Intel has a bad (i.e. kills performance) fix, but will not enable it by default because benchmarks matter.
2) This series of patches in particular appears to be doing either something different, or more than what their descriptions imply
These patches do various things, presumably to manipulate the opaque internal state of the CPU, but only Intel knows for sure precisely what they do.
I was under the impression that for at least one category of attack, there is no hardware mitigation possible because it's a fundamental problem with the x86-64 design. Fixing it would require building a chip that uses some other architecture. Is that not the case?
One obvious approach would be to have two caches per core. Speculative execution would use a different cache than normal execution. If the speculative action is committed to, it swaps which cache is the normal one and which is the speculative one. Then you'd also need to flush the branch predictor on context changes. And a few other issues.
Nothing that's impossible to do, but it would require a huge amount of new design and a lot more silicon just to maintain the performance of current chips without mitigation.
Yes a solid Spectre fix will obviously make designers rethink their microarch in some deep aspects. But somewhat good mitigations should be available as soon as the next chips, and off-by-default is completely utterly insane. The OS is not part of the platform (except in some special cases that can disable the mitigation for performance if they like), and the platform is supposed to be retro-compatible, maybe not perfectly but reasonably. Ok it has already been somewhat less true than before in the few recent year, but lets not encourage that behavior. So shipping new CPU that are broken by default but can be somewhat less broken as an opt-in is an attempt to mask the level of the fuck-up, or maybe to avoid the creation of a new stepping. We should not tolerate that from Intel, a stepping is expensive but they have the money to do it.
Did you mean to respond to someone else, maybe?
Of course, that'd probably need more complex logic to manage this new cache, which makes things more difficult. Then again, not sure how two caches interacts with potential speculation across multiple branches (does Intel even do that?)
> But since the peanut gallery is paying lots of attention it's probably worth explaining it a little more for their benefit.