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.
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 went in expecting the usual Linus ranting, and although he doesn't disappoint in that department, he also has a valid point.
As I understand it, Intel proposes to build in a switch in future CPU's which tells the CPU to stop being insecure. The switch is going to be off by default and must be switched on by the kernel during boot. Intel proposes to let all future CPU's be insecure by default.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
The only reason why many people need that 4Ghz to begin with is because of how bloated software has become.
And because sensors have got better giving us mych larger datasets. You know, sound, video and audio are the common ones.
I challenge you to find the bloat in FFMPEG, for example. Now try transcoding a HD video on a modern 4GHz desktop versus a 1st gen Raspberry Pi.
SJW n. One who posts facts.
AMD has one problem in common with Intel: Spectre. Meltdown is alone Intel's problem.
Meltdown is fairly easy to exploit and quite serious. Spectre could be as serious, but so far nobody has shown conclusively that it is actually exploitable in a real life situation. Intel spun it to make people think they're the same, so everyone thinks Intel and AMD have the same problem. They don't. Intel has a serious, potentially crippling security hole and a potentially serious but most likely not usable security hole. AMD only has the latter.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
(note that this fix requires to change the CPU design)
Slashdot, fix the reply notifications... You won't get away with it...
Somebody with mod-points should mod up the AC parent. They are completely correct.
The design flaw is not in using speculation or branch-predication. It is allowing the side-effects of instructions in those streams to be visible in the machine before the branches are retired. This is really basic stuff - I remember a discussion about this very issue in a processor design course back in '00 - '01.
Intel gambled that the state of the cache was not visible to the programmer. Flush+reload showed that they were wrong.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
And fundamental problems are still fundamental problems. The reason practically every processor has the same issues is because
Is because it doesn't. AMD is not vulnerable to MELTDOWN and is less vulnerable to SPECTRE because they are more scrupulous and responsible than Intel, FULL STOP. There is no other reasonable way to regard the situation.
Every speculative processor has some of the same issues, to some degree, but that is not every processor, and you are still using Intel's bullshit excuse FUD language when you say that all processors are vulnerable to these attacks. That is a lie as stated.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
AMD has one problem in common with Intel: Spectre. Meltdown is alone Intel's problem.
Not that it's germane to the AMD vs. Intel argument, but IBM got it wrong too. Power7 through Power9 processors are vulnerable to MELTDOWN, and mitigation will be expensive just as it is on Intel.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.'"
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 ]
240hz monitor and trying to get a steady 240fps. And boy do I mean steady. Even a blip between 240fps and 230fps can be perceived as microstutter, and that was with a gsync monitor. Gonna need a fast CPU to generate a frame in 1/240th of a second.
Wrong. Your frame rate is determined primarily by your GPU. The CPU component (for graphics rendering) is the API where the data goes from the CPU to the GPU. That is why we have DX12 and Vulkan, to get much closer to the metal. With games that are less demanding visually when you turn v-sync off with for example an i4790k Devils Canyon the frame rates goes way over 240fps even without Vulkan and DX12. So you see, there is no CPU bottleneck for graphics rendering. It's all GPU bound.
We'll make great pets
Why not? Somebody has to call bullshit on this.
What would you have him do, get some PR flunky to "corporatize" the message until nobody is really sure what it's all about?
Haiku yours is not The point missed by you it was It was a joke. Whoosh.
For what it's worth, your post isn't a haiku either. Nor was the original "Linus Haiku". A haiku need not have a 5-7-5 syllable structure; and a 5-7-5 syllable structure does not make something a haiku. Haiku require a cutting word (kireji), and carry imagery of the natural world.
These are closer to senryu than haiku.