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.
So Linus what are you proposing as the solution? or this just yet another useless rant. Respect everything you have done but Christ sometimes you go on with utter bullshit. Yes we all know the intel situation is shit, yes we all know the patches are fucking awful with huge performance impacts, but what other option have you come up with to avoid it?
If he wouldn't own the Intel stock because of this, you shouldn't buy Intel processors:
https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx
So, in 2017 Project Zero discovers the bug.
By November 17th the speed hit was explained by Alex Ionescu for the next version of Windows 10, without explaining why. So they knew it was a problem.
27th November 2017..... Intel CEO sells off quarter of a million shares, and a lot of sell offs across the boardroom, CFO etc. Chairman etc.
And here we are, they don't plan on fixing it. It will be as it was before for all but risky public servers so that Intel doesn't get sued. And if you buy an Intel machine, you won't know if the fix is turned on or off.
Meltdown is only an Intel x86 problem. ARM is not affected nor is AMD. It is an unsafe Intel optimization they did. Don't let them confuse you with 'Spectre' which is a *different* bug, merged into the press release to confuse the issue.
So if you need x86, of with Threadripper based AMD chips, and if you don't, go with ARM chips. AMD's threadripper is winning in benchmarks anyway, and is generally cheaper.
Intel's CEO bailed on the company, and you should bail on their products.
If he "commits suicide" for opposing globalist chicanery, all fingers will be pointed at Intel. This drama is pretty existential for those ass-clowns.
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?
How good are Intel engineers these days? Has their ability to fix problems gone up or down in the last few years?
This is Intel's problem to fix, and Intel has to fix it. The rest of the world has to call them out on any and all attempts by them to not fix it. Linus comments are therefore an integral part of the solution.
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
Need a faster PC, and all this seems to indicate that i'm currently better off not buying an Intel CPU.
Used to be a lot of clever spods in Cambridge where ARM started up(through Acorn).
Hopefully they are still working in the company in areas that matter as I know they'll fix this properly with no bastardisations (unlike other large semiconductor manufacturers that may have the subject in the main article)
ARM64 is good. A little weak in a couple of areas, but that should be easily (and correctly) improvable with motivation! Use it!
Change log:
2018/01/01 - Added 14 Useful Links. Disable Intel ME via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)
Intel CPU Backdoor Report
The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.
What we know about Intel CPU backdoors so far:
TL;DR version
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
30C3 Intel ME live hack:
[Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
@21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.
[Quotes] Vortrag:
"the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".
"We can permanently monitor the keyboard buffer on both operating system targets."
Decoding Intel backdoors:
The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.
If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).
Backdoor removal:
The backdoor firmware can be removed by following this guide using the me_cleaner script.
Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.
2017 Dec Update:
Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.
Useful links (Added 2018 Jan 1):
Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
me_cleaner: Set HAP AltMeDisable bit with -S option
Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
Sakaki's EFI Install Guide/Disabling the Intel Management Engine
Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
CVE-2017-5689: An unprivileged network attacker could gain
No, AMD has the same problem... at least across threads.
No AMD doesn't have the same problem, Intel cut corners so it'd be 5% faster in benchmarks, AMD didn't.
So fuck off.
If you think about the exploit for more than a couple of minutes that this (SPECTRE) is not just some stupid mistake all the CPU manufacturers made. It's a fundamental problem with our current CPU architectures and memory hierarchies. There is no way to fix it in current CPUs other than to disable speculation. And there is no way to fix it in future CPUs without some seriously complex hardware tacked on to keep track of speculated loads and later replay them into the cache, at every single level of the cache hierarchy.
It's going to be a complete clusterfuck.
So when they shove Intel ME exploits down your throat with no way to disable it, the excuse is "Some enterprise needs it"
When it comes to actual Intel security fixes, it's not forced, but optional?
Fuck Intel. It's just another NSA front like Facebook.
That is why you have to use both cpu stepping info AND CPUID.
Furthermore, CPUID features can be disabled in microcode when one of them turns out to be broken and the microcode fix is to disable the opcodes altogether. This happened with whatever generation the G3258 was in with one of the new features, which turned out to have some sort of internal timing issue that could cause crashes in rare cases leading to bios updates to disable the feature.
Only old people in Korea and Linus use email.
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.
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.
For comparison, how did ARM and AMD address these issues (the patches in question are Spectre patches) in Linux?
CAPTCHA: pharmacy
It's interesting that Linux kernel is, in theory, a non ideal kernel: while it has some modules, it's not a microkernel, and a lot of the modules still runs in the userspace. In this compromise, it delivers speed, when compared with real microkernels, but it loses security and stability. Like Intel, the reason why it got popular.
Period.
And by do, I mean do it right.
TL;DR of the TL;DR:
We all are fucked.
Linus’ tantrum is completely and utterly justified. Intel bet the company that their level of engineering review wouldn’t bet the company--and they lost.
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...
how do you really feel, Linus?
Intel needs their own kernel/distro for their bogus hardware. That's cool. If they come up with patches that make sense then they will be
merged upstream. If not, the most secure, fastest hardware available wins.
Sure it looks great on synthetic benchmarks, but honestly speculative execution is just asking hackers "hey come and root me". I'm sure Intel could fix it, but it would take a hit on benchmarks. They really need to fix this, even though it will take a benchmark hit. For regular day-to-day stuff, I seriously doubt users would see noticeable difference.
I'm not that old and don't live in Korea yet I use email and don't use Social Media.
I guess you are talking out of your gummed up, constipated ass then.
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.'"
Yeah, because spending millions of dollars to on planning, buying hardware, imaging, installing, testing, and migrating hundreds if not thousands of servers to replace a production data center or two as a massive overreaction is a super feasible plan.
Or you could install a patch that reduces performance but makes you secure right now (though if you are doing your job right as an administrator, your servers are not running with the CPU pegged anyway, because that would mean you under-provisioned for growth and scaling) and re-evaluate technology selections for current and future purchases, as well as evaluating the shortening of operational lifetime of installed equipment in order to swap out affected systems more rapidly, but at higher than projected budgeted costs. Note: higher, not 3x or 4x depending on how much operational lifetime your organization plans on.
"Just move to vendor X" is a great solution if you are just a guy with a laptop, and you were planning to replace that laptop anyway. It is not a feasible suggestion for any business that actually likes being profitable, and is a completely useless suggestion to any medium / large business. Plus, there's the "oh shit now AMD has a design flaw that nobody knew about for the last 10 years" possibility and you're back at square one - grimace and deploy the patch, or make some knee-jerk reaction and spend way too much money on something that isn't really a solution to the problem at hand.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
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 ]
Driving a patched Wolkswagen car controlled by a patched Intel CPU is the ultimate insane experience.
and some lawyer for AMD will sue if turned on by default on amd systems.
AMD I WANT desktop class IPMI board like intel E3 is.
I also wouldn't consider 12 years very old.
Which Javascript Framework are you referring to exactly?
Ooops! Now you've done it. Again!
https://www.theregister.co.uk/...
Cc: Andi Kleen "ak@linux.intel.com"
Cc: Andrea Arcangeli "aarcange@redhat.com"
Cc: Andy Lutomirski "luto@kernel.org"
Cc: Arjan van de Ven "arjan@linux.intel.com"
Cc: Ashok Raj "ashok.raj@intel.com"
Cc: Asit Mallick "asit.k.mallick@intel.com"
Cc: Borislav Petkov "bp@suse.de"
Cc: Dan Williams "dan.j.williams@intel.com"
Cc: Dave Hansen "dave.hansen@intel.com"
Cc: David Woodhouse "dwmw@amazon.co.uk"
Cc: Greg Kroah-Hartman "gregkh@linuxfoundation.org"
Cc: H. Peter Anvin "hpa@zytor.com"
Cc: Ingo Molnar "mingo@redhat.com"
Cc: Janakarajan Natarajan "Janakarajan.Natarajan@amd.com"
Cc; Joerg Roedel "joro@8bytes.org"
Cc: Jun Nakajima "jun.nakajima@intel.com"
Cc: Laura Abbott "labbott@redhat.com"
Cc: Linus Torvalds "torvalds@linux-foundation.org"
Cc: Masami Hiramatsu "mhiramat@kernel.org"
Cc: Paolo Bonzini "pbonzini@redhat.com"
Cc: Peter Zijlstra "peterz@infradead.org"
Cc: Radim Krcmar "rkrcmar@redhat.com"
Cc: Thomas Gleixner "tglx@linutronix.de"
Cc: Tim Chen "tim.c.chen@linux.intel.com"
Cc: Tom Lendacky "thomas.lendacky@amd.com"
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: x86@kernel.org
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 ]
FUCKWIT
Rather than trying to fix that which increasingly seems to be unfixable at the microcode level, perhaps a different tact is needed.
The two attack vectors are through executing malicious javascript code through a web browser and the other would be downloading malicious programs and/or having physical access to the computer. The latter problem might be tackled by allowing only "certified" known programs that are not malicious to be executed on the computer. Which would mean controlling the program from origination to delivery perhaps with a "Linux registry". You would be right to roll your eyes, but the situation we are in is not exactly pretty either. There could be a specific control program to turn off this feature for those who would wish, such as those compiling their own code. Plus, it would not need to be executed on computers that do not have the faulty CPUs.
To counter the former (attack via web browser), Intel's patch could be enabled while the web browser was operating (as that generally will be less performance critical imho). Perhaps eventually the browser could examine a trusted certificate before letting a web page load.
It would be trivial to granulate these further and offer a combination of the two as they are needed. In a sense, you are "locking down" which programs are allowed to run in user space. I certainly agree that these options are quite ugly, but they are options nonetheless. But as I see it, that's where we are at.
Who knows though - this might could be seen as an opportunity. If Linux is the only operating system that can offer a solution such as this, maybe its desktop market share might grow rapidly. Maybe at one point it might could bring about "The Year of the Linux Desktop".
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
it may be possible to then do spectre in the opposite direction...preload the cache and if any preloaded pages become slower
That would presumably be a LOT harder since the cache is shared so any process running can cause the cache to flush and you typically do not have control over what gets flushed. However, the only real way to fix this is to check for a valid address before anything gets loaded. That way the branch will immediately terminate and, if it gets selected for execution, will immediately cause a memory error. This could even improve performance by reducing memory bandwidth caused by false branches.
You are ranting about other people ranting, without offering solution.
So fuck off.
Its a hardware thing, so best anyone can do is throw some code at it to prevent exposure best they can. This adds a layer so speed can be affected. The real solution comes when new chips are designed in the hardware to prevent this exposure. Spectre is going to be a issue as long as there are chips that are exposed to it.
How come my favourite Poettering ,of systemd fame, is not Cc'd?
I wasn't lying. They are still vulnerable to that one class of spectre. I would assume they've had the same time to fix this problem.
You're lying and you're talking bullshit base on "I would assume".
Intel cut corners, patented the corner cut, which caused Meltdown, that AMD isn't vulnerable to, now they pretend nothing major happened.
Fuck off and stop trying to pretend Spectre is on the same league as Meltdown.
It's the normal way to communicate in the adult world of the workplace. Ask your mom about it.
The issue is with making insecure mode the default one, passing the ball to the OS. This is a damage control PR mode, and INTEL's being called on their bullshit.They said the patch didn't had performance impact, but they don't have the balls to make it the default mode.
So this is to Intel what Dieselgate was to Volkswagon?
Ultimately Virtual memory is the root of all the following decisions that brought us to this point. If the entire page table could fit in chip memory then one wouldn't need a TLB, or splitting. Nor even rings and modes but that's a side-benefit.
Talk about "old" : In Korea, Email Is Only For Old People.
You probably don't want IPMI.
- Russ Bielawski
"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.
Sounds like the solution would be easy then. Just make the hashes bigger. You're a genius.
Why is Intels solution so bad? They think, that any complete Spectre fix will seriously limit branch prediction, ie slow down systems. And there are system were speed is more important than the security issue (eg because the system are used for some offline workload). So why not opt in (as opt-out can be probably be exploited easily).
And seriously, if fixing one bug costs 5%-10% performance, how many similiar bugs can be solved ? (And don't tell me that this is the last bug needing to be solved before the system is perfect).
What if your computer is running in a rather secure isolated environment? Why default to the patched version which will slow everything down?
Plaintext Supermicro IPMI Credentials Exposed
https://threatpost.com/plaintext-supermicro-ipmi-credentials-exposed/106784/
IPMI: The most dangerous protocol you've never heard of
IPMI could be punching holes in your corporate defenses.
https://www.itworld.com/article/2708437/security/ipmi--the-most-dangerous-protocol-you-ve-never-heard-of.html
It's right there.
Your Intel CPU and Chipset is running a backdoor as we speak.
The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.
But apparently Opportunit is too stupid to understand.
You know, like, join up with a company that designs CPUs
And run them right into the fucking ground with his "nothing is good enough for me" attitude..
Does anybody really care what Linus thinks? Why is this even posted here?
You seem to have bought into the cool-aid. Please add a healthy dose of critical thinking. Because this isn't the kind of cool-aid that makes for a fun trip with pretty pictures. This is the kind that melts your brain.
It's not that it's a nasty hack. It's much worse than that.
That's part of the big problem here. The speculation control cpuid stuff shows that Intel actually seems to plan on doing the right thing for meltdown (the main question being _when_). Which is not a huge surprise, since it should be easy to fix, and it's a really honking big hole to drive through. Not doing the right thing for meltdown would be completely unacceptable. So the IBRS garbage implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation. Honestly, that's completely unacceptable too.
It's not "weird" at all. It's 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.
BULLSHIT. Have you _looked_ at the patches you are talking about? You should have - several of them bear your name. 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. 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. 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? And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed by morons. It's mis-designed for two major reasons: - the "the interface implies Intel will never fix it" reason. See the difference between IBRS_ALL and RDCL_NO. One implies Intel will fix something. The other does not. Do you really think that is acceptable? - the "there is no performance indicator". 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.
I want to see the hockey puck moving like lightning on the ice. Okay?
"No fear. No envy. No meanness." Liam Clancy
The world seems to be going more mobile. I know a few people who use their phone as the only computer.
Why not have ARM notebooks, maybe running some modified version of Android?
I suppose the apps, and drivers, are not there yet. But it seems like they could be.
Linus: So the IBRS garbage implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
Linus is bringing up the issue that Intel may never fix the spectre bug in hardware, even in the future. That's what got Linus (and me) outraged.
Is Intel going to sell defective CPUs in the future where the kernel flushes the branch target buffer (conditional speculation stuff) every time context switches to mitigate Spectre? That's a slow-ass CPU and we don't want that.
Fantastic idea. I bet Gov't intel (pun intended) agencies will applaud users being aware of all the holes and back doors in their system.
~Any apparent grammatical or typographic errors are caused by defects in your display device.
Let's not forget that Intel's CEO sold the maximum number of shares he was allowed to suspiciously close to (before) this bug was public.
https://www.fool.com/investing...
~Any apparent grammatical or typographic errors are caused by defects in your display device.
after 20+ years at the evil-i, i'm no fan, but torvald is a whiney little bitch. seriously, the intel engineer actually provided a pragmatic explanation for a quick fix AND a plan to phase out the hack. and torvald just ignored him and made a bunch of cringe-worthy cliches.
this comes from linus never really having been beholden to a market before. if linus was in charge of a $100B company, he'd think differently, but he's not, so its his sandbox and he can scream and cry all he wants. fortunately i don't have to listen. feel bad for those who do.
There has been angst with the OpenBSD developers too. Seems like they've managed to piss everyone off.
He'd definitely know since he's produced a lot of complete and utter garbage.
ARM has reported that some of their processors are impacted.
ARM has reported that some of their processors are impacted.
The Cortex-A75 is supposedly vulnerable to all variants.
Intel PR flaks have been telling the world that this is not a big problem and that the performance hit to fix it will be minimal....
so it what Intel is telling the public is true then the performance hit should be so small that nobody minds having it, even in an isolated system. The idea that you might prefer to run unpatched for performance reasons implies that the performance hit is indeed noticeable.
It cannot be both ways.
Documented here - this is the only CPU listed by ARM as vulnerable to CVE-2017-5754.
Probably the only straight shooter in the software world at all. You're all lucky to have him because everybody else is deceiving your and pulling your strings. You're all idiots!
Your definition of "ideal" is rejected.
Plenty of other CPU architectures have similar SPECTRE flaws including POWER and latest ARM
Microkernels have security and stabliity problems too, get your head out of the ivory tower books and go read the patches for them sometime.
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!"
I guess Linus was right again.
So easy to criticize. If this is such a big problem, even though apparently no one has exploited it yet, please tell us all how to fix it. Or is the answer switching over to your Linux system, which may be better theoretically, but most people don't want to spend months figuring out how to use it?
Unfortunately for intel, the proper fix also slows down their processors. Or to put it other way around: intel cheated and made it look like their CPUs are fast by omitting important features. This "fix" will show the true speed of intel CPUs.
I wouldn't call it "stupid". It is rather easy to in hindsight look back and criticize something that now might seem stupid. Like using two digits for year data. Like 640k is big enough for anyone. You could probably list of a host of examples.
In this instance it seems to go back to 1995. However that is production release. Which means the design and decisions made for that was probably in the early 1990's. Now think back to how things were back then. The internet? Ha! Hacking? Ha! Exploits? Ha!
You could argue that things should have been re-evaluated, and updated as circumstances changed. Then again, perhaps the guy(s) who were really aware of all that stuff retired, or were laid off? Perhaps it just never occurred to anyone that it was all that exploitable. Or it could be that they did know about it, did a bit of risk assessment and figured the performance hit wasn't worth the minute risk that anyone would figure out how to exploit it in any meaningfully way (i.e. a business decision). Remember, while there have been "proofs in concept" of these exploits, to my knowledge no actual malicious hacker (i.e. not a researcher, etc...) has yet to exploit it in any meaningful way that anyone is aware of.
Anyway to call it "stupid" is a bit of hubris. If I had to guess it was done that way back in the day because it really didn't matter. Intel probably knew about it for a long time, and at certain points did business risk assessments to decide that it was better to just ignore it than do anything about it really. Now it seems they are finally paying the price... They don't call it *risk* assessment for nothing.