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?
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?
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
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
Used to be a lot of clever spods in Cambridge where ARM started up(through Acorn
In British English SPOD is an acronym - Sole Purpose Obtain Degree for a student who is academically good but socially reclusive.
Just a lump of ice for all you septics on /.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
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.
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.
You can fix it.
You just need to ensure that you treat speculative loads in a way such that they can't reveal information. Say, another cache just for speculative loads. This would also mean you don't clutter up the normal cache with the non-used results, and for the brief moment that you're executing down a path you're using already-cached results, just from another cache. No reason that can't then send a hint or even directly transfer to the main cache.
The problem is really: Is fixing it worth while compared to just turning it off? Given that there are chips that are capable of doing speculative loads without hitting such problems (because they do proper permissions checks and/or have the caching in the right places), it's perfectly feasible that we'll be fixing the problem in the future rather than just avoiding it.
The problem is already in every production processor anyway, so it's already going to be a mess. But there's no reason you can't fix it.
Intel's problem was patenting a certain technique unique to themselves... everyone else avoided at least some of the problem by doing things differently, and yet was still able to compete.
Another couple of years, and processors will be advertising speculative caches or whatever the solution is, in their feature bits.
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.
Well after 10 years of only building AMD boxes for myself, this year I built my first Intel box. Their described "solution" leaves me with little confidence. Fast and unsecure by default seems contrary to every security model I'm aware of. We may as well go back to logging in as administrator or root while we're at it. Lucky me. Lesson learned.
I buy Xeons for workstation loads and high reliability requirements. I am able to disable prefetching/problematic speculation through the BIOS (similar to this), thanks to the extensive functionality that seems to be on motherboard (I've noticed Xeon boards generally have a lot more options generally).
What is AMD's alternative? In the past it was branded Opteron, but I am struggling to find a modern variant that's comparable to Intel's top end Xeons along with the ability to disable prefetching.
Change is certain; progress is not obligatory.
> The problem is really: Is fixing it worth while compared to just turning it off? Given that there are chips that are capable of doing speculative loads without hitting such problems (because they do proper permissions checks and/or have the caching in the right places), it's perfectly feasible that we'll be fixing the problem in the future rather than just avoiding it.
Meltdown is about permission checks. Spectre is in every CPU that does speculative execution beyond cache misses.
Yes, you can have a separate cache that is just for speculative loads. When speculation turns out to be wrong, you clean that cache. Easy.
But when it is right, what then? You now have to transfer all the loads from the point of speculation up to the next point of speculation (for CPU's that speculate further ahead than one branch). So this means you need a way to keep track of that information. And you need to transmit it all the way up the cache hierarchy, otherwise you can do the same attack at level 2 or 3. or whatever the highest non-shared cache is.
Yes, I agree, future generation CPUs will probably fix this, but it is not just a simple "just add some extra cache".
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...
how do you really feel, Linus?
Zen CCX = four cores.
Ryzen (4-8 cores) = Two CCX connected using infinity fabric on the same chip.
ThreadRipper (8-16 cores) and Epyc (? - 32 cores) = Four Ryzen chips also connected with infinity fabric on the same interposer.
Or something such.
Epyc & ThreadRipper: https://cdn.wccftech.com/wp-co...
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.'"
Selling Intel stock might have been a bad long term prospect. For the first time in years we can expect the next generation of Intel CPUs to be noticeably faster than the previous generation. A year from now Intel is going to be selling a lot more CPUs then they are now.
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 ]
The Xeons have ECC memory support - this is why Intel can charge so much more for a Xeon then an i7. It is basically a money grab by Intel. The Ryzen all have ECC memory support - assuming it is supported by the motherboard. So you can get your high reliability requirements from a standard Ryzen. Of course, Epyc has additional cores for more processing power and Epyc systems are designed expecting the use of ECC memory - so they are probably a safer bet if you have the spare cash. But they are a safer bet only because the non-CPU components in the system will be designed with matching reliability.
So it depends on your application but if you are really interested in data integrity, like most workstation applications, then the Ryzen with ECC memory should be fantastic.
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.
It's also quite likely that additional vulnerabilities will be found in AMD processors, now that everybody is looking at these types of vulnerabilities.
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 ]
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.
How come my favourite Poettering ,of systemd fame, is not Cc'd?
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.
"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.
What if your computer is running in a rather secure isolated environment? Why default to the patched version which will slow everything down?
It seems to me that there should be a register flag that can turn off various types of CPU optimization features explicitly. Then the user can do decide if the optimization on or off. Make a bunch of switches to turn on and off different types of optimization in the CPU.
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...
A compiler fix is fine, but will take a long time as you still need to recompile everything using the new fixed compiler...
This may be relatively easy for open source, but closed source code will take a lot longer and some of it will never get fixed.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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
https://www.theguardian.com/ed...
"Lump of ice" (advice)
Which to receive sometimes can be very cold comfort.
It's worth pointing out this is incredibly obscure and may well have been invented by Guardian journalist keen to pad their article out to the minimum word limit. Unlike 'septic', which was originally an armed forces thing from the friendly but bantering relationship between the US and UK but has now spread to the point almost all Brits are aware of it .
https://www.urbandictionary.co...
Cockney rhyming slang for a yank (american). The whole phrase is 'Septic Tank' - but as with most cockney rhyming slang the first word is used only. The reason for the link is that, like a septic tank nobody likes a filthy stinking american!!!
What are you fucking shooting at me for you filthy fucking septic cunt, im on your side!!!!
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
There are several confirmed security issues with the pod bay doors and they have therefore been disabled for your safety. Your oxygen reserve is five minutes. Have a nice day.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Some variants of Spectre work on every modern CPU, but Intel is uniquely vulnerable and requires the most performance penalties in mitigating it.
There has been angst with the OpenBSD developers too. Seems like they've managed to piss everyone off.
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.
Documented here - this is the only CPU listed by ARM as vulnerable to CVE-2017-5754.
Many thanks. Didn't realize the connection to Cockney rhyming slang, which I find to be a rather peculiar yet engaging form of linguistic expression, especially when the rhyming word is no where to be found in the actual utterance.
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!"
How good are Intel engineers these days? Has their ability to fix problems gone up or down in the last few years?
I get the feeling from what Bob Colwell has said in different forums that just before he left, the management level above the engineers was being filled with people less interested in technical excellence and more interested in politics for lack of a better term. This is consistent with various Intel policies since then like excessive market segmentation.
I guess Linus was right again.
That's in silicon, so no easy hotfix for existing CPUs, but that would be essentially what's needed to protect new releases. Would work on Meltdown no problem.
Spectre would be harder to overcome as it utilizes timing mechanisms - essentially a calculation that is already cached ends way faster than a brand new one, which allows to guess results of prior calculations. The attack is extremely slow though, taking literally many hours of operation at full CPI load to read a significant part of memory - and it's read-only; can leak keys/hashes but can't directly escalate privileges or execute malicious code. I guess detecting the exploit program's activity and disabling it before it obtains anything of value would be easier than protecting the CPU (which currently essentially depends on flushing the cache before switching to protected content, so that no successful cache hits are there to be found.)
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.