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.
And how does excluding 80-90% of the installed user base help Linux exactly?
I understand the sentiment, it's just not a professional way of handling the situation.
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.
While that is completely true, saying it doesn't solve the problem.
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.
The only way you can guarantee the designs are error free are to abandon everything that makes modern processors fast - OOO, speculation, branch prediction, and plenty more, including potentially pipelining (the fundamental technology everyone is trying to speed up by avoiding pipeline stalls). Go back to the old fetch-and-execute cycle and where memory operands are fully decoded and retrieved prior to even considering fetching the next instruction.
Everyone will hate it, because now your 4GHz processor will be as fast as a 500MHz one.
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.
The only reason why many people need that 4Ghz to begin with is because of how bloated software has become.
Avantgarde Hebrew science fiction
While that is completely true, saying it doesn't solve the problem.
It is no more Linus' problem to solve than it is your or mine.
It is entirely up to Intel to do this and do it properly.
Thank goodness Linus is saying this, because it will force Intel to solve it.
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.
Why is fixing it Linus' job? He pointed out, accurately, that Intel's fix is for this Intel problem is complete bullshit. The importance of this is that he has stripped away Intel's efforts to portray its fix as something we should accept.
I applaud the man. Linus has proved that the Emperor has no clothes. It isn't his job to serve as his tailor.
Linus is the gatekeeper to the kernel. He decides what goes in, if he doesn't allow it in then it is up to him to be responsible for mitigating the security risk involved. So either accept the liability or have a better solution, I doubt he is willing to accept the legal liability.
Your comment is marked Insightful, 4 -- but it is overall totally wrong. You are presenting a false dichotomy!
The issue with Spectre is not that there is a fundamental problem with branch prediction (or BP misses, or pipelining, or speculation, or any combination of these). The issue is that some processors don't actually clean up after themselves when branch mis-prediction occurs. They roll back instruction execution in some cases (great). In others cases they may simply abandon execution (okay). But they don't ever do so much rollback work as to invalidate cache lines (bad!).
There is such a thing as provably reversible computation and storage, and it can be done correctly. But you have to limit the length of instructions over which you will continue to speculate to something you can reverse; and you **have** to flush cached information that should have never been available in the first place.
If everyone was still running with 640x480 and PC speakers the way they were supposed to
640x480? lol n00b.
No we should be running in 40x25 teletext mode like god intended. Or are we meant to be in 80x25 VT100 like we were supposed to? Or are we supposed to be running on electricomechanicla teletypes like we were supposed to?
Or are we meant to be running on punched cards like we were supposed to? Or front panel switches?
Als the PC speaker was always shite even by the standards of the day. We should all be running the Ti.SN76489 as we're supposed to.
. The biggest issue with computers is seemingly ever-present need to build entertainment machines out of them. If we just did away with the entertainment requirements
OK, I'll bite.
Suppose we did as you wished, and separated off entertainment to a different enclave. How do you suppose one would make such entertainment? Them PCs are awfully convenient and it helps to have a fast one.
we would be just fine with 500MHz CPUs.
Yeah... no. I like having a massive, fast machine with huge screens for coding even I'm targeting an 8051 or some sort with a few k of RAM. I also want fast machines for scientific data processing. We have better languages and better optimizers than were practical two decades ago and I like it.
If I'm runing some factory test rig or octoprint on my 3D printer, that 500MHz CPU is just fine and that's what I use (well they're faster now).
Who the fuck really needs FFMPEG anyway?
Anyone who deals with video. Like computer vision researchers too of which I am one.
But they have the money to build render farms for their needs. What do the rest of us really need 4K video for?
A news for nerds website is not really the best place t obe a luddite.
SJW n. One who posts facts.
The only reason why many people need that 4Ghz to begin with is because of how bloated software has become.
What an ignorant and useless comment. Software bloat is a very minor portion of what it is our computers do. Almost none of what makes up bloat in software ever even comes close to pegging the CPU and would give you a few percent speed increase at the most.
What we do depend on CPUs now is raw computing power. I was fine with a 500MHz PC back when my digital camera had a floppy disc in the back, now that it generates a 50mpxl 14bpp file it's not going to cut it and that has nothing to do with the relative bloat of the image viewer.
Likewise for web browsers. It's not bloat to blame for the fact I expect a browser to be able to stream a 4K movie in surround sound. It's not bloat to blame for the 40 tabs I run concurrently. It's not bloat that I have 10 office apps open along side video conferencing software along with those browser windows.
And among all that my CPU is sitting at 30% utilisation, 25% of which is being taken up by a full system virus scan (fuck monday mornings on my work machine).
Spare us your "we could make this less bloated and we would all be happy with 500MHz" garbage.
IMHO, Intel is basically operating in PR-nightmare-cleanup-mode right now.
They fucked up badly and are trying to lie, cheat and manipulate their way out of it.
They are desperately trying to make it look like this is a generic problem (It's not; the AMD and ARM variants of these bugs are much less evil) and they are trying to safe face and shift blame however they can.
Plain and simple truth is that Intel has knowingly made malicious choices and now they've been caught.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
This is the correct answer. Proceed to Go and collect your $200.
You may want set aside more silicon for caching and less for handling the speculation.
You may also want more cores rather than greater complexity. This would not have been a good choice ten years ago, but now people are learning how to use the extra cores, it will probably sell well.
Alternatively, you could set a flag to say whether your application cares about the risk (if the entire machine is dedicated to a single offline task, you probably don't).
Sent from my ASR33 using ASCII
It's not a normal design compromise. AMD isn't affected by Meltdown because they did it right, Intel cut corners to get a small performance boost that they didn't need.
Worse still, Intel's botched microcode fix can brick systems. Apparently 7 months wasn't enough to properly test it.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Nobody is claiming Linus is being unprofessional or Intel is being professional, they are claiming that excluding Intel support from the kernel would be unprofessional, which is why it is never going to happen.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
And why is all that javascript needed? Usually as a hacky method of writing something that could have been implemented better (improving html/css), as a way to prevent users from controlling their app (web apps), or as malware (trackers, and now apparently miners).b
Avantgarde Hebrew science fiction
"be the OS that is still susceptible to this flaw after everyone else isn't."
This patch does not fix the problem anyway. It is a patch to bypass the fix by default so that NEW intel processors do no loose speed (but will loose the security).
All Linus has to do is ignore this patch and run every Intel new and old processor with the fixes. It'll run them slower, but they are atleast somewhat more secure.
And your idiotic intel fanboy.
I understand the sentiment, it's just not a professional way of handling the situation.
Linus always tells it like it is, which you can either view as professional or not. But from an engineering perspective, it seems better to do that than just say something polite so you don't upset people.
It appears to me he's directing his displeasure at Intel management/legal/marketing making decisions where really they shouldn't.
And how does excluding 80-90% of the installed user base help Linux exactly?
I very much doubt he's going to do anything of the sort. I would suggest the exact opposite in fact; he wants the best solution for all and is complaining that Intel's patches are constructed for their own benefit (legal/ass-covering), rather than that of their customers.
to get a small performance boost that they didn't need.
So since when does a CPU company compete on anything other than performance of that CPU? Or are you suggesting we all buy Intel CPU's because we love the IME? :-)
Linus proclaims thus: This patch is a piece of shit. So what else is new?
If you mean "useful, straight communication from Linus as usual", then I'm with ya.
But if you're trying to imply that Linus indiscriminately calls *everything* a piece of shit, then you're so offbase that I'll wonder if you're astroturfing on behalf of Intel. When Linus criticizes stuff, he's spot on. This patch is indeed a piece of shit.
- First they ignore you, then they laugh at you, then ???, then profit.