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.
From the email correspondance; Linus says to mr Woodhouse:
"As it is, the patches are COMPLETE AND UTTER GARBAGE.
They do literally insane things. They do things that do not make
sense. That makes all your arguments questionable and suspicious. The
patches do things that are not sane.
WHAT THE F*CK IS GOING ON?"
In the post, Linus is not addressing much technical detail (just mentions "garbage MSR writes" whatever than means), but his bullshit detector goes off big time.
It is clear that he thinks the patches are sub-optimal, but that in itself cannot be the first time in Linux kernel history. There seems to be something else behind, or why would he ask "WHAT THE F*CK IS GOING ON" question? Why does he play the "questionable" and "suspicious" card? Does he think that there is something shady going on from Intel, that goes beyond the technical stuff?
Can anyone shed some light?
Intel should fix this, but realistically they cannot come and replace the silicon on your chip, and most cpus are out of production or soldered in notebooks. So what? We're in an apollo-13-like situation, we must fix things with what is possible, no matter how ugly.
Ryzen 7 1st gen vs Intel i7 8th gen is something like 15% faster in multi-core vs 15% faster in gaming work-loads. About. There's variations like AVX (where Intel HEDT is faster still relative the i7) and games where the performance impact is closer to 40%. The Ryzen 7 chip and motherboard is cheaper. ThreadRipper socket is cool.
With Ryzen 2000-series for the "2600" engineering sample the clock was 200 MHz higher. Guess we'll see if it stop at that or not.
The AMD chips have a bit more PCI-express lanes and are less affected by this too.
So.. do as you want. For a specific use-case like a video program or sound-production which doesn't fully utilize additional cores and depend on more on per core performance or AVX maybe Intel is better. For multi-threaded ALU work and now maybe for virtualization and storage performance maybe AMD is better.
We'll all be winners if you buy AMD though. I guess.
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 it just my impression that Intel didn't do squat during the past half year, and only started searching for fixes now that the vulnerabilities are public?
What's also shocking to me, Intel is introducing new CPU models to the market that still don't have the flaws fixed. They really think the whole problem is overrated and no urgent action is needed.
How good are Intel engineers these days?
About as good as Volkswagen's. Both followed their remit perfectly (Intel: Performance above all else, VW: pass the emissions test above all else)
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.
EPYC is the Opteron successor. Cannot say about disabling prefetching thought.
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...
They knew damn well it was shady. It was widely discussed at the time. And then they patented it so AMD could not do it!
Intel are up to their neck in it.
Sent from my ASR33 using ASCII
Intel has billions of dollars in cash on hand, let alone their yearly profits. They could spend some of that compensating people.
But no, Intel is a corporation, and consequences are for little people.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Intel chose to behave in this fashion while AMD (and literally everyone else) did it the correct way.
Correction, everyone else but IBM, whose Power7 through Power9 processors are also vulnerable and where mitigation will be expensive. How far POWER has fallen, from the PPC601 where everything was done right... to today. (PPC601 was actually a POWER processor in a sense, in that it actually implemented the full ISA.)
"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.'"
Why? Intel had to recall Pentiums due to the FDIV bug and that was arguably way less serious than Meltdown.
That was just P54Cs. This is every intel processor since the Pentium Pro. And many of the motherboards will require BIOS updates to take a newer processor, so even if Intel could make new processors which fit into the same package and solve these problems, they literally wouldn't work in a huge number of scenarios — especially OEM PCs whose BIOS is designed to carefully restrict which processors and memory you're allowed to install.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Or maybe starting up a serious open source hardware spec. He's probably one of the few people with the knowledge of what chips need to have, an audience,
He might have the knowledge of what a ship needs to have,
but the last time he tried making a chip it didn't work that well~
---
Note: I'm just playing silly. I actually admire the guy for what his done (Linux, Git, etc.) but I couldn't resis pointing out that he DID already try making a CPU.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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 ]
"If there is anything we've learned from this debacle, it's that arrogance runs supreme at Intel."
The arrogance and attempts to mislead seem to be a present-day response to problems created during years of ignorance. Intel's recent CEOs have not had the enthusiasm for technology or the social ability necessary to manage Intel, in my opinion. Intel suffered from insufficient management 11 1/2 years ago: More Intel employees should say in public what they have said in private: Intel CEO Paul Otellini is not a competent leader. He lacks social ability.
Flaws increase sales? Intel's sales have been lower because people are happy with the computers they have, and also often use cell phones as their personal computers. If Intel begins selling new processors and chipsets with no vulnerabilities and no back doors, will that increase Intel's sales?
An example of flaws increasing sales: Microsoft's Windows Vista OS had problems. That caused more people to buy Windows 7 when it was released.
It was kind of you to decode SPOD. Thank you.
Now could you do the same for:
The closest Google got me was the dangers of flushing toilets in a house using a septic system that had iced up in the winter time, and I'm not sure that is where you were going...
Linus said some bad words about Intel's behavior to Mr. Woodhouse, an Amazon employee.
Amazon is a major cloud provider.
Linus is now in his late 40s.
So.... the headline should read "OLD MAN YELLS AT CLOUD! CLOUD ANSWERS!"