Slashdot Mirror
Linus Torvalds Calls Intel Patches 'Complete and Utter Garbage' (lkml.org)
An anonymous reader writes:
On the Linux Kernel Mailing List, Linus Torvalds ended up responding to a long-time kernel developer (and former Intel engineer) who'd been describing a new microcode feature addressing Indirect Branch Restricted Speculation "where a future CPU will advertise 'I am able to be not broken' and then you have to set the IBRS bit once at boot time to *ask* it not to be broken."
Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.
Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.
You are right, Linus, as usual.
But I'd prefer the Linux Kernel Development team to push a complete proposal on the table.
Like totally ditching the support to Intels starting with the releases on next March 1st (or better April?).
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Linus proclaims thus:
This patch is a piece of shit.
So what else is new?
Don't forget guys Intel are the biggest contributor of code to the Linux kernel and it was they who wrote that code that would have crippled AMD as well as Intel cpus against their own flaw. Luckily AMD picked up on it and submitted a "elseif" statement to Intels code so AMD users wouldn't be neeedlessly affected by Intels cpu flaw.
I think his response to all of this was a verbal kick to the scrotum of intel in a very public way.
I am glad of it too, had it not been for this thread I would not have known about the issues with these 'patches' which now seem more like last minute frantically cobbled together garbage.
Because of linus' efforts I, and many other lurkers here on slashdot will be VERY wary of any 'updates' involving intel cpu's.
Linus does not need to fix this, the community does not need to fix this, Intel needs to fix this, lets be realistic.
Linus is pointing out that the patches as submitted do things that should not be necessary. For example, the Linux kernel now uses this code technique called “retpoline” to avoid one of the Spectre bug variants. But this set of new patches also includes a performance-hurting workaround for the same Spectre variant that was already worked around. Why would that be necessary? It suggests that maybe Intel isn’t fully disclosing everything that they know, and that maybe the “retpoline” workaround is insufficient for reasons that Intel is keeping secret.
He's saying that you shouldn't have to "opt-in" to the security that everybody expects when you boot up your processor.
At the moment, the processor just says "Hey, if you flip some magic bits when I boot I'll slow myself down and try to apply a fix".
The processor should instead say "Hey, I'm one of the fixed models, don't bother trying to fix me again".
It's a marketing / legal tactic so they can say the processor runs at such-a-speed (but insecurely) whereas anyone who actually cares about using the processor has to - every boot - flips lots of magic bits to make it secure and kill its performance. If you forget, insecure. If you do it wrong, insecure. If your OS doesn't support it, insecure.
What Linus wants, and I can't disagree with, is a flag to this "this processor isn't vulnerable, so you don't need to do anything." which, if it's not present, they know that they have to apply as many protections as they can but can say "Hey, you have an insecure processor, we'll do our best" in the syslogs.
My reading also. Intel did some shady things they likely did know were shady in order to have the best performance. Now that they have been caught and the shady things actually turn out to be really bad, they still do not want to fix them, because they do not want to admit how much they padded the performance of their chips and they still do not want to compete with an actually good design because everybody will see how they have been screwed over by Intel.
Linux is just calling that out. I mean, a functionality that fixes a very critical security bug and it is _off_ by default? That is insane!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
ARM does not have to fix anything for the issue under discussion and neither has AMD. Meltdown is Intel only. They did it to get more performance while everybody else was careful and did not do it. Intel was warned by numerous research papers that this could go badly. Now they are lying about it and are trying to a) confuse the issue and b) have the fix (which exposes their real performance when running securely) not active at startup. a) is dishonorable and b) is insane. Linus is just calling them out here.
Spectre is something else, and hits almost everybody. While fortunately, it is much, much harder to exploit (Meltdown is easy), Spectre will also be much harder to fix. It is possible that we will see an arms-race for a while with Spectre and that, in the end, it will need to be a compiler-level fix that finally fixes things. Not good, but apparently, the performance penalties for an actual hardware fix at this time would be a performance loss of 5x...20x.
But to re-iterate: The only reason why Intel tries to lump Meltdown and Spectre together is so that they do not look as grossly incompetent and dismissive of their customers's security as they are with Meltdown.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Is there a tl;dr version of that tl;dr version?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
You make some really interesting points around retpoline, but I wonder if this latest from Intel fails to account for this because they are being disingenuous, or because they continue to be a bunch of idiots?
We're seeing similar problems to this with other very-long-established technologies, such as Windows [with Windows 10]. Things that have worked for decades up until W10 are breaking, or they are breaking in new and frustrating ways.
For example, I have a triple-screen setup and using removable SSDs via a caddy unit, I can boot my computer into 2 different W10 instances, as well as multiple Linux builds. The 2 W10 instances behave in completely different ways, despite being set up, by me, with EXACTLY the same approach [scripted]. On one of them the Task Bar keeps relocating itself around the desktop, on the other it remains static. I've been back-and-forth with Microsoft and they don't know why...
At the root of the problem I suspect they have changed something in W10, written by someone no longer at the company, possibly poorly documented and possibly with unknown consequences.
Maybe Intel are having similar issues... A decision was made a very long time ago to do something insecure and stupid with speculative execution, but the person who made that decision is no longer with the company, so a new Team are trying to fix it and simply don't know what they're doing...
I honestly don't know what the source is, but I do know that I am seeing "existing" functionality break with much greater frequency on core platforms like this. It just smacks of carelessness...
But i have to say, even as i prefer AMD, AMD does not have spectre resistant CPUs either.
Yes, they do. SPECTRE attacks are more difficult to carry out against AMD than against Intel. In fact, they are only vulnerable to one out of two of the classes of SPECTRE attack. Please don't lie.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
we must fix things with what is possible, no matter how ugly.
Intel went straight to ugly, and did not satisfactorily explore the realm of the possible. Linus perceived this, and announced it to the world. The ball is now in Intel's court. They can be responsible and competent, or the whole world can know that they are the fuckups that they are. It's their call.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
And fundamental problems are still fundamental problems. The reason practically every processor has the same issues is because the same optimizations we used to make processors faster had the same fundamental design error.
I mean, either someone designed the core branch predictor block and everyone worldwide copied it for every processor, or everyone implemented it differently, yet it has the same Spectre flaw, implying that the flaw is inherent in the way branch predictors work.
Well, there are different level in the whole Spectre/Meltdown debacle.
Not all CPU are affected the same.
(And nitpicking : only CPUs doing speculative execution are affected. Lots of RISC don't, only some recent like 64bits ARM cores do. And there are still CISC cores that don't even in modern days like older Atoms and Xeon Phi on Intel MIC boards).
Speculative execution, from the moment it was presented (around the era of Intel Pentium Pro) as a new technology, was criticised as potentially executing past important checks if the speculation goes wrong. But it was dismissed back then. ...because back in those days (in the era of RC4 and 3DES encryption, MD4 MD5 checksums, etc.), attacking cryptography was still done by breaking imperfect algorithms and brute forcing small search spaces. Timing side channel where something of academic interests only. Known to exist, but in practice there are simple way to attack encryption.
- because in the end, nothing is committed to memory/register, but instead is discarded. There are not (direct) permanent effect of the wrong speculation.
- nobody paid attention much to the indirect, less significant effects, that still could be measured (like bringing memory into cache).
-
(so nobody in the early-to-mid 90s would have though that cache could lead to useable exploitable attack).
"Spectre" is just some researcher figuring out a way to exploit this "known from the beginning" knowledge by putting it into the light of how crypto is attacked nowadays (side-channels, timing, etc.)
That's the thing which every single CPU is affected by and which is still speculative execution working as it should (and normally should still be contained to data that could be accessed by the application anyway).
But then, there are the cause of the "Spectre Variants / Meltdown" - due to "excessive" optimisations, suddenly the CPU not only access things that the application could already access anyway. It usually boils down to the CPU (and its designer) were trying to be way to smart.
Meltdown only exclusively affects Intel CPUs. On intel CPUs, to speed things up, memory protection check are post-poned. If something happens to be already available in the cache, speculative execusion might pick it up even if it violates memory protection.
This runs countrary of how memory location works, is undocumented (unlike the base caracteristics of speculative execution).
(AMD CPU, as a counter example, are guaranteed by AMD to not be affected, because they do the expensive checks at the beginning of the pipeline and never let speculation through if it reads from an unauthorised memory location. There everything works according to docs).
Spectre variants affects Intel CPUs: to speed things up, even if the destination of a jump is unknown (because it depends on a memory location that isn't even known yet: e.g. not-yet computed index of a jump table), an Intel will try to speculate where the execution would go (by keeping a list to remember where usually this poistion ends-up jumping to). Due to the specific way Intel CPUs work internally and keep this list of "possible destinations of a jump", it can get confused and jump to an impossible situation. the speculative execution will jump to an address that is not even in the jump table, it will execute at a position that could never be reach under normal circumstance.
(AMD cannot exclude if their CPUs are affected. They definitely do not work the same wa
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]