Slashdot Mirror
Intel Responds To Alleged Chip Flaw, Claims Effects Won't Significantly Impact Average Users (hothardware.com)
An anonymous reader quotes a report from Hot Hardware: The tech blogosphere lit up yesterday afternoon after reports of a critical bug in modern Intel processors has the potential to seriously impact systems running Windows, Linux and macOS. The alleged bug is so severe that it cannot be corrected with a microcode update, and instead, OS manufacturers are being forced to address the issue with software updates, which in some instances requires a redesign of the kernel software. Some early performance benchmarks have even suggested that patches to fix the bug could result in a performance hit of as much as 30 percent. Since reports on the issues of exploded over the past 24 hours, Intel is looking to cut through the noise and tell its side of the story. The details of the exploit and software/firmware updates to address the matter at hand were scheduled to go live next week. However, Intel says that it is speaking out early to combat "inaccurate media reports."
Intel acknowledges that the exploit has "the potential to improperly gather sensitive data from computing devices that are operating as designed." The company further goes on state that "these exploits do not have the potential to corrupt, modify or delete data." The company goes on to state that the "average computer user" will be negligibly affected by any software fixes, and that any negative performance outcomes "will be mitigated over time." In a classic case of trying to point fingers at everyone else, Intel says that "many different vendors' processors" are vulnerable to these exploits. You can read the full statement here.
Intel acknowledges that the exploit has "the potential to improperly gather sensitive data from computing devices that are operating as designed." The company further goes on state that "these exploits do not have the potential to corrupt, modify or delete data." The company goes on to state that the "average computer user" will be negligibly affected by any software fixes, and that any negative performance outcomes "will be mitigated over time." In a classic case of trying to point fingers at everyone else, Intel says that "many different vendors' processors" are vulnerable to these exploits. You can read the full statement here.
What about video streaming (writing, compressing) with Intel's Quicksync? We do a lot of I/O. Presumably it's going to kill our performance. I wonder if a class action lawsuit will be incoming.
panic button pressed
"Intel believes its products are the most secure in the world"
Yeah, more secure than all those other products who don't let you log in with an empty password.
"First they came for the slanderers and i said nothing."
why are non broken AMD chips flagged intel?
Like, who, AMD? Who said they don't have the flaw?
Let me see.....ops, there is no other vendor actually.
And who gives a s*t for the average user. Its the enterprise who are going to suffer, and suffer BIG.
Even 5% decrease in performance could mean lost business.
From Tom Lendacky
Subject [PATCH] x86/cpu, x86/pti: Do not enable PTI on AMD processors
Date Tue, 26 Dec 2017 23:43:54 -0600
share 0
share 2k
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Nice try Intel, but phoronix benchmarks prove you wrong, and show even up to 60! % loss in some loads.
There's no way they tested this properly before the release.
I'm sure nothing will happen, as there is no accountability anymore unless you are a Democrat.
Intel says "Intel believes these exploits do not have the potential to corrupt, modify or delete data."
They do not say anything about read. This means exploit lets read protected memory.
you may recall they claimed the pentum floating point bug would affect people only slightly.
when using the number 4,195,835 = 0x4005FB and 3,145,727 = 0x2FFFFF. The '5' in 0x4005 triggers the fault in the FPU control logic. As a result, the value returned by a flawed Pentium processor is incorrect at or beyond four digits
https://en.wikipedia.org/wiki/...
"Publicly, Intel acknowledged the floating-point flaw, but claimed that it was not serious and would not affect most users. Intel offered to replace processors to users who could prove that they were affected. However, although most independent estimates found the bug to be of little importance and would have negligible effect on most users, it caused a great public outcry. Companies like IBM (whose IBM 5x86C microprocessor competed at that time with the Intel Pentium line) joined the condemnation."
Some drink at the fountain of knowledge. Others just gargle.
I'm running around 1,000 servers.
I think their magic excuse 8-ball is broken too, cause I think this is the exact same excuse they've used for all their previous screw ups too.
Intel fanboys take it up the backdoor once again. Stockholm syndrome.
All my users are above average.
OK, that's back of the envelope and with the usual caveats, but everybody wants one number.
I wonder, does the average computer owner also have a bank account or conduct any transactions with vendors whose websites are hosted on shared instance cloud computers? (hint: that would be everyone except maybe kim jong). You are impacted by this even if it's not a computer you own. Furthermore, while we don't know the full details of this, it's entirely plausible that the program running in user space could be a web page javascript, java plugin or adobe flash program. If so such web pages could harvest your private data including website passwords, your bitcoin key, or any number of things you don't want leaking.
Some drink at the fountain of knowledge. Others just gargle.
why is intel saying many different vendors?? When there BIG revel AMD does not have this bug.
I like how they've weaseled out of the whole fiasco (why didn't /. post a link to the original press release?):
"Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time".
I'm not sure I can read between the lines properly but I guess new revisions of Coffee Lake/Kaby Lake/SkyLake(X) CPUs are coming and they will contain a hardware fix (though it still seems highly unlikely considering how difficult it's to deploy a new hardware design - however unlike other fabless companies, like AMD/NVIDIA/ARM/etc Intel has everything under control). After all they've known about this issue for almost half a year.
Meanwhile as for consumer workloads they are correct. Two German websites have already tested a Windows build with a fix and found very little performance losses.
Phoronix has also run a number of tests on Linux and found out that only few (mostly artificial) tasks are seriously affected.
Intel home users may sleep well. As for enterprise customers no one has run virtualization tests yet though - that's what truly important for large deployments (clouds).
The rest doesn't cut through the noise but adds to it.
I'm waiting these answers from Intel ...
What will happen these modern flaw chips from stock and from the industries? Billions to be lost!!!
Or not!, still selling these flaw chips?
I'm waiting the announce of these negative profits from Intel ...
When they had the Pentium floating point division bug they also said it wouldn't affect the average user. All they did was piss off their customers before they recalled the chips anyway.
Some people never learn.
If the 'sensitive information' they can gather includes credentials or tokens the user wouldn't otherwise have access to, it sure as shit allows modification of data
Remember Intel's management engine, their $F00F bug, and their "special" C compiler shenanigans. How long have they known about this screw-up? Longer than they will admit, I'm sure.
That was one of the most uninformative, denying-we-did-anything-wrong press releases I've read in a long while. Therefore I suspect it came from the legal team. If only Intel's CPU designers were as good as the Intel legal team.
I downloaded tool ( https://www.intel.com/content/www/us/en/support/articles/000025619/software.html ) from Intel and it says that my computer is not affected by it. But the patch provided by AMD makes it look like Linux-patch will cause every CPU to be slow without actually checking if the CPU is vulnerable or not. So now I'm more worried about slow computer than the security issue.
I am a bit confused by the Intel tool also as my CPU and ME version are on the vulnerable list, but because my mei fwu platform is SMALL instead of FULL, the tool claims that I am not affected. I have no idea what that means, but it seems that on older systems only FULL platforms are affected.
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
I am sure Intel knew about this and was hoping no one would discover it. Just like a defective car, the processors should be recalled or replaced IMHO. Make these companies pay for their mistakes like they make all their customers.
And then we have to turn it off on every machine to gain better performance. Pretending that your hardware runs faster than what it does, doesn't make it run faster.
Seriously - anyone who knows enough should know that this bug (being able to read tiny amounts of kmem ONLY during a specific sequence of speculative instructions; bad but hardly an open port) requires: malware to already be running on your system (in which case you are already screwed); that malware to be so perfectly crafted to not only read tiny amounts of kmem data via specific instruction sequences but then expand that tiny amount of info into some (magical?) process for gathering passwords, crypto-keys, etc. (none of which are stored in kmem anyway, but why spoil the panic parade?) and then spreading to other computers on your network. Show me a real POC, then we can panic. FFS!
Does not "corrupt, modify or delete data". Yes, nice. It can just steal your passwords and encryption keys and then use them to do that corruption, modification or deletion. A shameless lie by misdirection. Intel has no honor at all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Now I have nothing to complain about. Get the same performance with a much lower price.
My understanding is this hits virtual machines harder than most other applications. I know some people run a Windows VM on Linux boxes, and some even game on them using GPU pass-thru, so how would that be affected?
As Intel has been caught red-handed doing massively illegal things several times, like any good criminal enterprise they of course have a first-rate legal team.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
https://www.fool.com/investing...
But if he helped backdoor ME maybe he won't get prosecuted.
That still exists and is almost all Intel based CPU's. Now that is something to worry about. No patch, kernel or otherwise, to fix that one.
Reading about this so far gives me the impression that this bug only allows reading the *location* of kernel memory, not its contents. The bug is triggered by trying to read an inaccessible page and discerning the difference in timing of the failure to distinguish between "page does not exist" and "page belongs to the kernel and you can't read it". This basically breaks KASLR and nothing else. I do not see how this lets you actually read kernel memory. The only impact is that now malware could exploit kernel buffer overflows that already exist. This is not the end of the world; we have lived just fine before ASLR and can live just fine now that it's broken. Fix kernel buffer-overflow bugs and this is a total non-issue.
I am surprised how niave you are. Slashdot is mostly made up of IT professionals. Servers are the WORST hit by this issue. Docker, Containers, the cloud, vir
tualization is severely affected by this issue. This has massive implications for everything. On the consumer side I would be surprised if Games weren't adver
sly affected. Honestly the only type of workload that is less affected is probably Office type workloads.
Wow, sounds like they sent somebody to the basement to retrieve the "Pentium Floating Point Bug Response Plan" binder.
Although, to be honest, those have security holes in them as well.
-- Tigger warning: This post may contain tiggers! --
Enough with speculation. All the details have just been revealed:
Source: Reading privileged memory with a side-channel
Website: Meltdown and Spectre
AMD CPUs are susceptible to one of the attacks.
I'm still waiting for a firmware update that fixes the not-so-recent Minix debacle in my Skylake NUC. I'm just not buying any other Intel chip in years.
The PR is phrased and written in such a way that indicates only one goal was in mind: to try and keep stock prices from plummeting. Any time a large corporation issues a PR response, this is their #1 focus, technical details and engineering facts be damned. Intel's CEO selling US$11M worth of stock mid-December doesn't help either (the issue at hand was given to Intel, AMD, and other companies in June of 2017).
If you read the full report this issue may not completely go away but its certainly not something you can really take a chance of not patching just because you think your system will slow. This vulnerability also affects some ARM and AMD processors even though some reports say no. The people who discovered the flaw say they have proved its exploitable in AMD, Intel, and ARM. Apple has claimed to have patched already in November, ARM is working on a fix, and Linux has patches out as well. Windows will no doubt have a fix by patch Tuesday. Look up Meltdown and Spectre to find out more.
and seeing how Intel artificially inflated their prices by over 100% until AMD could compete in the top segment, I am sure as hell never buying from Intel again. Fuck you Intel.
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
Basically, this isn't an implementation bug, or even a design flaw... it's an architectural flaw, present in all modern CPUs. Unless great care is taken, any CPU that supports both speculative execution and memory caching is vulnerable. This is incredibly huge. To a first approximation, all computers are broken.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
*sigh*
Whores.
Someone needs to shoot some executives. Soon.
... any negative performance outcomes "will be mitigated over time."
Meaning, when you buy a new CPU or computer - i.e. "fixed in the next release".
It must have been something you assimilated. . . .
From what I've read, this "problem" looks to be a design decision on the part of Intel. Speculative access needs to be fast, and making it subject to access control basically removes the benefit of speculative access.
Given how Intel the company operates, there's no way that this could be a bug
I myself would rather run with the current behavior, since I don't particularly care about the problem; it's more an issue for shared hardware, and I don't generally share my hardware.
Bullshit? Look at the table in this from ARM listing all the affected ARM architecture processors from ARM.
"This mission is too important to allow you to jeopardize it." -- HAL
Just love the wording there, where they "embrace" AMD in the press release, implying that they (AMD) also have the bug. Bah.
As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently. Why? Let me set the scene: It’s late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: “We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are” - I’m paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn’t explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn’t seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
It's basically the same fuck-up as in the software industry: Profits and "time-to-market" prioritized over security.
You'll note that neither AMD is a Ryzen.
To be fair, the existing laws are vague enough that good lawyers can talk judges and juries out of severe penalties. Thus, it's not technically "illegal", or at least not clearly illegal. "Devious" is probably a better word than "illegal". They dance in the grey areas of the law.
It's also the main reason why Hillary (and other tech-sloppy politicians) are unlikely to be prosecuted. Vagueness is a key tool of powerful lawyers and why regular folks are less likely to get away with stuff that plutocrats like OJ and Hillary get away with.
(I've been round and round in the Hillary email thing in many forums, and there are no known clear-cut laws to bust her on. Criminal prosecutions require "beyond a reasonable doubt". The law and the tech landscape provide plenty of doubt.)
Table-ized A.I.
have the potential to improperly gather sensitive data from computing devices that are operating as designed
Intel believes these exploits do not have the potential to corrupt, modify or delete data.
This is a false statement.
When you steal "sensitive data" from said "computing devices" that are "operating as designed". You obviously have "potential" to obtain the means to "corrupt, modify or delete data".
Recent reports that these exploits are caused by a âoebugâ or a âoeflawâ and are unique to Intel products are incorrect. ...
are susceptible to these exploits
So the problem with Intel hardware is not a "bug" or "flaw" but rather an "exploit"? Exploits by definition are "exploiting" "flaws". Either flaws in implementation or design unless of course Intel is asserting speculative execution machinery in its hardware was supposed to enable leaking contents of memory which would of course be much worse for Intel than admitting to an innocent mistake or oversight.
Intel is committed to product and customer security and is working closely with many other technology companies, including AMD
Wording is an obvious attempt to create a linkage between this issue and AMD processors while AMD is publically saying NONE of Intel's problems apply to them.
Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
Meaningless drivel. One could disable processor static ram caches and make the same nebulous characterizations. The "average computer user"'s processor sits mostly idle while actively using their systems.
However, Intel is making this statement today because of the current inaccurate media reports.
Intel is making false statements.
Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers
Intel is delusional.
The most secure products in the world come with a management engine insecure by design while harboring known exploits and yet Intel over numerous years has consistently refused it's customers simple request to provide a means of turning the blasted thing off. Creating unnecessary and unwelcomed vectors for compromise is not something the vendor who produces the most secure products in the world would even contemplate much less make good on. Intel's approach to security is a joke.
Stop spreading lies. Intel is fucked, AMD isn't.
As shown, AMD was only vulnerable to "the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries."
Intel PR monkeys are trying to take AMD down with them, let's make this clear:
For the 3 bugs, the biggest one only affect Intel CPUs, for bug 2 and 3:
AMD bug only affect THE SAME PROCESS, unlike Intel, which allows exploit to cross process
https://googleprojectzero.blog...
As shown, AMD was only vulnerable to "the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries."
I think it was 1 or 2 months ago a researcher found it and disclosed it.
The Linux kernel has a patch already but it seems not like a real solution.
Intel has a history of doing things like this and always get away.
The questioner said "We do a lot of I/O". If you do io 512 bytes at a time, this may be noticeable. But that was a poor choice to begin with. 8192 bytes can be a lot faster, even without this issue, and even more so now. Each disk read is a call into kernel space. To minimize the number of calls, grab more data each time.
Try different values and benchmark. It can make a big difference.
Integrated graphics on Intel use the same page table mechanism as the CPU. Fire up a shader program from userland and snapshot as much of the OS kernel as you like. Or you know, buy an AMD system.
Intel users are part of the problem with their, "we're better than that AMD crap".
Intel us just taking the lead from Trump.
Branch predictions errors were made, on both sides. Both sides!
Aka AMD is not at risk. A process is SUPPOSED to be able to read its OWN memory. Which means branch mispredictions included.
AMD Ryzen and Threadripper and ravenridge and Bristol ridge and the last few Opterons and even the Phenoms are not at risk.
The false equivalence bullshit is bad enough in politics, we don't need it in tech.
If you want to say "bad people.on both sides, both sides", name the specific CPU model at risk for AMD. Here u will do Intel's list:
Everything since at least and including the core2duo.
They had to do it, but it is a little... ummm...
Kill all humans...
Do any of you people actually understand what the alledged vulnerability is about or do you just screem foul?
C'mon you're better than that.
If it's not really a problem and fixing it produces no performance hit, then Intel should prove this by:
1. Release full documentation on the flaw/non-flaw, both to openly explain this "design feature" and to prove they are talking about the same thing the security experts and OS coders are. It's just too easy for some PR flak and team of lawyers to issue a boilerplate "nothing to see here..." statement and then later when shown to have lied to say "ooooh, gee wiz, golly, THAT's not the thingy WE were talking about..."
2. Release the fixes, open-source with full docs and comments with proof that the new code executes in zero clock cycles, or if it is replacement code for what's already in Linux or Windows it should execute in no more clocks than the code it replaces. Oh, and the new code/patches must use no more memory and thus not introduce any performance hits when loading or by indirectly inducing a performance hit by any increased memeory useage.
Intel seems to have a very low view of the intelligence and competence of their customers if they think a vague statement like theirs, accompanied by no code, no data, no docs, no benchmarks, no examples - NOTHING technical, will suffice here. They ought to remember that as vendors of microprocessors their primary customers are technical people who care about DATA, not arm waving and hollow PR.
Apple for funky flashman duty? Heck, we play up this six-month old Intel crap to take the heat off Apple and then they stiff you on payoff. Typical.
So does that mean that you can read those keys by using this bug?
Intel said that that bug didn't matter to plebian users either https://gigglebytes.wordpress....
A 30% performance hit means CPUs sips 30% more juice. Which means (almost) 30% more heat in the data center. Which means air-conditioners snarf 30% more electricity to cool it all back down. Not to mention additional SMPS losses.
So, a 60% spike! Maybe sell INTC and invest in electricity company shares? :-)
This is taking decades to sink in, starting all the way from people sharing games on floppies. Apparently nothing was learned from Word macros, Java, Flash. Every time new technology is supposed to magically deliver perfect security. I think now it's Javascript? Guess what, it can't. Stuff running on your device can misuse legitimate permissions for nefarious purposes and use bugs or side channels to get access to things you have not granted it. You might as well leave your financial documents in a desk drawer of your AirBnb rental. If people are determined, they can get to your stuff if you let them in.
lets them have access to us secretly whenever they want.. kind of like hidden AMD passwords, and NSA Key's, and holes put in things deliberately..
the only reason to know why this happened is if you did psychic warfare probing on the bastards that designed all these components.
DO NOT TRUST ANY AMERICAN MADE PIECES OF SHIT.
https://www.trumpsweapon.com/
AMD's Zen processors are immune to all 3 vulnerabilities FYI.
Oh, Intel has been caught in massively illegal things they could not talk themselves out of. Just think of the $800M they had to pay to AMD due to illegal (read: criminal) business practices.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That is still a pretty serious flaw
Yeah, I'm sure a user-land process being able to leak it's own memory space is a serious flaw... Yay!...
(The only way Google could even demonstrate it, is by enabling some non-standard kernel setting that let you sent eBPF (the byte code used by the packet filter) into a JIT which will run it in-kernel. Thus in-kernel process has access to in-kernel memory space. And you get what you deserve for inviting user-supplied code to run in-kernel)
Yes, you can also time stuff to get information from speculative execution on AMD CPUs.
Except that, due to better security hardware implementation you CANNOT use this to get information accross the kernel fence straight into user space.
With Intel, you end up with a situation where some Javascript code (demo'd at CCC) running in one of your browser tabs could be leaking information straight out of your kernel.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
They are affected, but not by Meltdown but by Spectre
To expand :
The whole shit storm affecting Intel, is about boundary violations.
That means kernel information leaking into user-land software.
Intel CPU are affected by this (they check access rights much later on, at a point where a lot has happened and that "lot" can be carefully timed and analyzed to leak information out of the kernel space). It allows to have information cross the boundary between kernel and users-space.
AMD CPU are not affect by this (they check access rights ealier, at a point where not much has happened yet). Yes you can also do timing to guess stuff from speculative execution, BUT you are shut out of the kernel space. You can only user this to have one process leak its own memory space. You cannot use this to get things from the kernel into some javscript code, the CPU will block access to early for the attack to actually work.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Yeah so the fact that some obscure ARM64 demo board that hasn't seen that much actual real-world deployment (*) happens to be made by AMD, means that suddenly everybody must lose confidence in all x86-64 hardware, not only Intel's (which is totally affected by the security shit storm) but also AMD's (whose AMD64 is immune to the actual security leaking exploit. It's not affected by the security shit storm. It's just affected by some proof of concepts where an application can leak it's own memory space) ?
While technically, the words of Intel aren't completely wrong (yup, there exist an obscure chip made by AMD that is affected), it's completely misleading: they want to make you think that it's affecting all manufacturer across the board similarly. It's not. Most of what AMD produces, all the chips you might be thinking about when thinking of AMD (i.e.: the AMD64 chips that make a sizeable chunk of AMD's production, and nearly all of their CPU production), they are not affected.
---
*: honnestly, are there any significant number of machine shipped with Opteron-A ? I mean actual servers deployed in production widescale, not some SBC sold in small quantity to people wanting to experiment with the tech.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
AMD does not have the read-kernel-memory flaw but it does have the read-other-userland-process-memory flaw.
I'll have to re-read the google publication, but I was under the impression that a process can only leak it's own memory space.
(because that one is just about out-of-bound accesses).
The javascript would need to somehow convince your ssh-agent to run some code in its address space to successfully extract the keys.
Basically each process has a different memory map.
Some addresses maps to its own data (for obvious reasons).
Some addresses maps to kernel stuff (so it can call system calls : filesystem accesses, etc.)
There's no address that the Javascript could attempt to read to trigger anything dependent on the ssh-agent.
It can only access addresses that refer to the data of the browser executing it (or more precisely, the current browser process - in case of multi-processing browser like Google's Chrome, or like the post-WebExtentsions-only-no-XUL FireFox's Electrolysis. It won't be able to even see other tabs: there's no memory address that would point to that content)
The only way the Project Zero proof of concept worked was by using a non standard setting to send eBPF (the bytecode used by modern packet filtering) into a JIT that run-it in-kernel (so basically it's an in-kernel process that leaks its own in-kernel data, and you get what you deserve for allowing user-supplied (byte-)code to run in-kernel).
And according to the various docs, the mitigiation against these forms of attacks is rather trivial.
the Intel CPU-specific flaw is an entirely different can of worm.
Most crucially, the mitigation against it comes at a ginormous performance cost.
Basically, each time your app calls into the kernel (e.g.: calls the filesystem to read something from a file), the kernel needs to flush itself out of the accessible memory. On Intel's CPUs, each system call will suddenly come at the same cost as a whole multi-processing switch, even if all happens within the same process.
Each single system call now comes with a craptastic performance hit.
Intel saying that it won't affect significantly average end users ? (Well in the same way the pentium floating point didn't affect them ?)
Well, maybe average users that only use their machine to surf Facebook. They have been running machine way much powerful than needed any way (very seldom do they have any core saturated at 100% use), so they simply won't be noticing the ~30% performance hit. (Who care if their web page loade in 50ms or 100ms ? It's twice the speed, but still under the noticeable threshold).
But for lots of power users (e.g.: gamers) that performance hit is going to be painfully noticeable.
It's going to show up in benchmarks.
It's going to show up in CPU intensive tasks.
It's going to drive a bit some of the market choices.
About the only truly users who won't be affect that much, is scientist running computations that mostly do number crunching (not much kernel switching involved).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
AMD can be vulnerable in some situations.
And those situations are a process leaking it's own memory space.
You need to first manage to send code to be executed in the memory space of something containing the interesting information to be able to get it, you can't do it from your own process.
(e.g.: Google's Project Zero managed to exploit a non-standard kernel setting that allow you to send eBPF - the bytecode used by modern packet filtering - to a JIT that will run it in-kernel. It's in-kernel software access in-kernel data. You get what you deserve for inviting user-supplied code into your kernel).
On the other hand the Intel CPU flaw allows you around the boundaries that are normally guaranteed by memory protection.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
As I read it, best case, all of userland is compromised.
Not *all* the user land.
Only all the memory space that is accessible to the process being abused.
In the AMD case, a user-land exploit (or in-kernel, with some weird kernel settings to allow such code to happen) can only leak information from the memory it has access to (Yay!).
It means that an app can leak some of its information even if it didn't want to.
And it means that if you get the kernel to execute some user supplied (JITed byte-)code, the kernel can leak some kernel data (but nobody sane should enable non-standard options that invite user-supplied code in the kernel).
An process cannot leak information from another process that it cannot "see" (= it needs to have the other process' data mapped into its current address space, in order to have an address to read from).
Any protection guarantee that stem from memory protection still hold true.
In the Intel case, the main take-home message, is that suddenly memory protection doesn't hold true any more.
A process can guess data at any address, even if it doesn't have the access rights to that location.
Which is several order of magnitude of "scary" above the former situation.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It basically boils down to system calls.
To mitigate the Intel CPU bug, each time your software calls a kernel function (e.g.: filesystem, to access a file), the kernel needs to flush it self out of the accessible address space.
Basically each single system call suddenly comes at the same cost that a full blown task switching.
Benchmarks that call a lot of system call (basically, anything that isn't purely 100% number crunching. i.e.: nearly any real-world application) are going to get a big hit.
Spinning disk aren't affected much (waiting for the big latencies until data gets there is dwarfed by the call hits).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Actually, when a user-land process contains sensitive data and can run arbitrary code, it is a serious flaw.
Yup.
And in the case of today's bugs, the level of "arbitrary" is concerned.
- Without the bug, one would need full absolute control like reading from any random memory location. If there's a check against reading this, you can't get the content. If the code doesn't offer you full unrestrained pointer math, you can't do this.
- With the bug affecting AMD too, even if the code tries somewhat limit you in what you are allowed to read (the boundary check heralded by the Rust-troll that show-up when ever there's a buffer overflow exploit mentioned), the check might not have completed by the time the read-access is starting to enter the pipeline and you could end-up having measurable leaks (side channels).
- With the bug that affects Intel-only, none of the guarantees offered by memory protection holds true anymore. You can as well throw your MMU out of the window. Even if memory protection should prevent a piece of software reading the kernel's data, that can be leaked too.
For example a web browser: contains in its memory space user passwords, authentication tokens, private keys etc. and can run arbitrary code from a remote source (Javascript).
Which is why browser like Google's Chrome, and like the elecrolysis that Mozilla's Firefox managed to enable once the big XUL-to-WebExtension switch happened (or the separate process used for Flash back in the WebExtension era), try to isolate stuff in separate process.
i.e.:
- Ideally the password managing bits and the tabs running remotely provided javascript should be kept in separate process that can't see each other.
- In practice there was recent mention of some password manager pre-filling forms in tabs (under some circumstances this can happen in Firefox) and thus making it visible to the javascript running there.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Except this bug predates 2013. I know it's hard when facts don't conform to your bias, but you'll survive.
The world is made by those who show up for the job.
Intel acknowledges that the exploit has "the potential to improperly gather sensitive data from computing devices that are operating as designed."
Don't Windows 10 and Intel ME "improperly gather sensitive data?" What's the big deal?
I believe this was very similar to Intel's statement about the FDIV bug.
Let's see what they're saying in a week.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
This meeting apparently happened in 2013, at which time vulnerabile chips had already been going out the door for years.
So while cutting corners is bad, the pre-corner-cutting validation team had already missed this.
I couldn't find a copy of the FDIV releases, that was back in the day, but I bet they're comically similar.
Here's hoping the lawyers put the screws to them just for that PR.
This is what Intel answered:
No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices â" with many different vendorsâ(TM) processors and operating systems â" are susceptible to these exploits.
It's called LYING.