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.
"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?
Yeah, notice the part where they tried to spread the blame to other CPU manufacturers.
"First they came for the slanderers and i said nothing."
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.
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 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.
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).
You'll now be running 1200-1600 servers depending on your workload.
Custom electronics and digital signage for your business: www.evcircuits.com
Some ARM64 chips are affected as well actually. Citation: https://lwn.net/Articles/74039...
I don't see why they would name AMD since it's unaffected however. https://lkml.org/lkml/2017/12/...
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
when did AMD say that? all reports say that both AMD and ARM are also affected
AMD CPUs are NOT affected. Quit spreading lies.
https://lkml.org/lkml/2017/12/27/2
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.
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
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.
This is on a computer. Apparently, you have no clue what that means. So to educate you (futile, I know): Computers can do tiny things very fast and very often and that results in not-tiny things. You argument is bogus.
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.
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.
Because other CPU manufacturers are pumping out devices that have this issue, and have done so for years.
ARM64 is also affected - and includes chips made by virtually every silicon maker, including AMD, Apple, Samsung, Texas Instruments, Renesas, STMircro, Microchip, Broadcomm, Qualcomm, and others. They are in virtually every recent tablet or smartphone.
Even the decidedly non-Intel Raspberry Pi 3 is affected.
AMD's AMD64 may be unaffected, but AMD's Opteron-A processors are absolutely affected.
-- Sometimes you have to turn the lights off in order to see.
For the average home user, are you saying this is a full-alarm fire?
I get why server farms are stocking up on Depends, but if I'm at home on a script-blocking browser, isn't my attack vector pretty small?
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
AMD does not have the flaw. Try to keep up.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This bug is FUCKWIT, it's a new one and still under embargo. The test you ran is the older ME bug.
Orationem pulchram non habens, scribo ista linea in lingua Latina
https://www.fool.com/investing...
But if he helped backdoor ME maybe he won't get prosecuted.
Actually, I've been knowledgeable about CPUs since the days when I was doing chip-level repair on DG Nova III CPU boards but...whatever. You still have not explained even a tiny bit how having malware on your system (necessary for this to be of any impact at all) is OK, but if that malware can read kmem...HORROR! Did any of the ransomware or anything else which has killed tens of thousands of systems read kmem? No.
Seriously?
There's a long, long history of people who should know better brushing off vulnerabities as impractical, unproven, theoretical, etc and being shown to be very wrong. "Panic" is a bit of a strong word, but you have to be seriously ignorant to brush off something like this with a "don't worry, there's no exploit".
Log in or piss off.
AMD's AMD64 chips don't have the flaw.
AMD's Opteron-A, however, is an ARM64 chip which does have the flaw.
-- Sometimes you have to turn the lights off in order to see.
The Linux and Windows kernels are being rewritten in a rather complicated fashion, which includes a performance hit. These changes will have a bigger impact than a typical security patch. No one wants to do something like this unless it is truly necessary.
If all of the developers who have the details agree that something needs to be done, I'm willing to go along with it. When the guys who build something are worried about it falling over, you pay attention.
I would rather not see a POC until a patch is released, tested, and deployed. The implications of this bug are dire, and malware authors can turn a POC into real-world malware in under 48 hours---simple, historical fact.
Vendors have seen security patches reverse-engineered to produce malware within a week, so I'd be inclined to push this onto workstations and public-facing servers ASAP. Full details aren't available publicly yet, so maybe the danger is overblown. But it looks very bad right now, all things considered.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
It's not "brushing off", it's perspective. A) You must already have malware for this to be able to run at all. B) Given how effective "standard" malware is (Ransomware) and C) how exponentially more difficult to implement this vector is.... I'm looking for a reason to take a 30%+ perf hit to guard against this most edgiest of edge cases.
What a load of bullshit.
The only ARM64's affected are those by Intel, because Intel "cleverly" re-used some of the low-level chip architecture.
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);
So any remote exploit or a multi-user server with a hostile user.
I stole this Sig
From Google's post: "Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host."
Source: http://security.googleblog.com...
So yes, for the average home user, no big deal. For anyone running something on a cloud provider, bigger deal that the host gets patched.
Gonna need some actual proof of this, Mr. Intel. They could be affected, that doesn't mean that they are.
Although, to be honest, those have security holes in them as well.
-- Tigger warning: This post may contain tiggers! --
The panic appears to be quite justified. The papers are out. I'm not yet done reading it, but so far what I gathered is this:
There's a demonstrated attack capable of dumping all of kernel memory at a speed of 503 KB/s. This is 34 minutes per GB, so a full dump is going to take a while at this rate, but it seems plenty fast to cause some huge amounts of trouble if the attacker knows where the juicy stuff is.
There's also a version for reading the memory of another process. This seems trickier to pull off, and the paper describes a speed of 10 KB/s of an unoptimized implementation.
Still, this appears to mean that any memory at all in the machine can be read, which is bad news for sure.
Also, this does not strictly require malware. This in my understanding means you can read memory belonging to other VMs on the same hardware, so all you need is to sign up for any random VM provider and you can poke around in whatever other customers are running.
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.
Scripts are only one of the many, many types of files that your browser must parse with perfection.
Ehhhhhh. To take advantage of this vulnerability, an attacker first must be able to run malicious code on the targeted system.
:-/ )
Again, if I'm not clicking ads and opening strange files, I'm really only worried about privilege escalation (Like Intel Management Engine
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
Show me a real POC, then we can panic.
Releasing details for a serious bug before making a fix available is the definition of a zero-day, and is a pretty stupid thing for Microsoft, or the Linux Foundation to do.
There appears to be an embargo on the details until the fix is distributed; grumblings have it pegged as mid-January before it's lifted.
Microsoft's Azure cloud has a scheduled reboot of all of their VM's on Jan 10th
, so we probably won't get any details until at least then.
I imagine Linux 4.15 will be released around the same timeframe.
-- Sometimes you have to turn the lights off in order to see.
Yeah, notice the part where they tried to spread the blame to other CPU manufacturers.
Yeah, and? There's plenty of blame to go around. Just because AMD isn't affected doesn't make their statement about other CPU manufacturers any less true.
Spoiler alert: This isn't even limited to x86.
It is not now, but if you do not patch when the patches become available, it may be soon. One problem is that it seems this is exploitable from within a browser sandbox, but it will take some time for the respective exploit-code to be written and working. At the very least you have a couple of weeks. And with a script-blocker, your attack vector is indeed small. But take care that things like PDF readers also execute code from the document in a sandbox and may be affected. At the moment this is unclear.
So don't panic but install the patches when they are finished and you should be fine.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The problem is malware in sandboxes (web-browser, PDF reader, VMs, Virus-scanners detecting behavior, etc.). Quite obviously though, but if you need that explanation, here it is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And that is relevant how? The whole discussion is 99.9...9% about AMD64.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Did you actually read the contents in detail, because the "tested processors" are not all equally vulnerable.
Prove it. Show us some concrete evidence on why this bug affects ARM. Shilling for Intel is no excuse for lack of proof.
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.
Turns out AMD CPUs are affected too. See https://spectreattack.com/ for details
Guess again. Spectre paper confirms that any webpage can read browser process memory from JavaScript. On AMD CPUs too.
Incorrect. From the FAQ on the page you linked to:
Which systems are affected by Meltdown? ... We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
My spoon is too big.
It's not clear to me that Spectre is the attack being talked about. If not, then it is disingenuous, or lying, to try to also blame other manufacturers. There was also a note on the linked page saying that Spectre is a more difficult to execute. They didn't say (at least in terms that I understood) how much more difficult, or whether local access was needed.
If the attack being discussed was what that page called "Meltdown" they didn't say that any chips other than those from Intel were affected.
I think we've pushed this "anyone can grow up to be president" thing too far.
No, it doesnâ(TM)t. Read their FAQ. The sploit was only tested on Intel.
My spoon is too big.
Do you visit websites? You are running code. That code can be malicious. And don't say "I only visit trusted sites". Those sites can be compromised. You don't need to click on an ad to run JavaScript.
Yes. It means you can read the contents. Google has a good overview of the bug and has proven that it works.
... 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. . . .
There are two attacks described in the papers. One applies only to Intel and allows you to read Kernel memory. The solution is to wipe page tables during switches to/from kernel mode.
The other attack applies to EVERY processor that does out-of-order execution and which leaves junk in the cache after rolling back a failed guess. It allows one userland process to read the entire memory of another userland process (i.e. a php script reading the contents of your sshd, though they haven't demonstrated that one yet). They do have an example of javascript reading the contents of the browser's memory, and they did it by crafting javascript that gets JIT'd into specific assembly instructions by Chrome's compiler.
The thing all of these attacks have in common is they must know the machine code being executed by the target, and be somewhat in control of their own machine code. I don't even see how they will stop the second attack other than clearing out the cache more frequently, but with multiple processors or hyperthreading and sharing the cache... there might not even BE a fix. I haven't read of one yet. (but the story is still developing)
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
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.
It already has. It begins by losing "p"'s. Hel !
Specter sounds like the worse of the two, to me, actually. In the paper for it they describe an attack where javascript is carefully crafted so that it generates specific processor instructions when compiled by the Chrome JIT compiler, and then the javascript is able to attack the browser host and read it's entire memory contents. And they have a working example of this supposedly.
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
There are two flaws. AMD does not have the read-kernel-memory flaw but it does have the read-other-userland-process-memory flaw. Imagine javascript reading your cached ssh agent keys.
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
IIUC the 30% performance hit was only against a synthetic workload, not anything that one would expect. The more normal hit was closer to 3%. Still not a pleasant change, but less disastrous. Additionally, someone said that if you were still using hard disks rather than SSDs, that you wouldn't notice, because it was hidden by disk latency. Perhaps they're right.
So basically, the patch is really annoying, and slows down your system, but it's necessary, and not crippling. Unless you are on an older Intel CPU with SSDs rather than disks, and you are running close to the limits of your system. Unless you are running a very unusual workload, that it is expected nobody is running except for tests.
Again, this is just my understanding, and is based on a summary of the above posts.
I think we've pushed this "anyone can grow up to be president" thing too far.
To jump from "We've got this proven attack scenario" to "That's all the attack does" seems extremely unwise.
I think we've pushed this "anyone can grow up to be president" thing too far.
It sounds like most program development should be unaffected. But I bet there are edge cases that aren't obvious.
I think we've pushed this "anyone can grow up to be president" thing too far.
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
Guess again. Empirically ZERO on AMD CPUs, only "verified the attack’s applicability to AMD Ryzen CPUs" and experimented on "Ryzen" . Where all the actual exploits were only on Intel machines. Rather bad of the researchers to lump what they actually exploited , and what they think they could exploit all mixed together.
Again AMD Ryzen was not exploited in any of their actual experiments, not to say it won't in the future.
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.
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.
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!
Heartbleed proved that attacks of this type are effective. And this can escape VMs, browsers, and other sandboxes.
Think of the fun you could have if you can steal AWS' or Google's SSL certs.
Anybody want to law odds on the NSA nudging Intel down this path?
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.
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."
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.
As long as you have the ability to connect to the other docker process and know which version of a service it is running, then yes. It's easier outside a container since you can just look at the path to the binary in the process list and then scan that binary and all its libs for an attack vector.
Mark of the Coder fades from you. You perform Opening on World of Warcraft. Warcraft crits GPA for 4. GPA dies.
It's called an Opportunity Button.
Buy a brand new Intel processor next year!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
Yeah, and?
And Intel sucks. What more do you want me to say?
After this and the empty password fiasco, you shouldn't waste your keystrokes defending them. Trying to defend a corporation is a waste of effort anyway.
"First they came for the slanderers and i said nothing."
I don't believe this is correct.
The Specter attack doesn't let bad code map memory from other processes. It merely allows bad code to explore memory with the process it runs in. i.e. dodgy javascript mapping entire memory layout of the browser it is running in but strictly within the bounds of the same process. Still a pretty power attack
Obligatory.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Read ARMâ(TM)s own statement.
They list four variants of vulnerability, and includes the following ARM cortex designs:
* R7
* R8
* A8
* A9
* A15
* A17
* A57 (Includes AMDâ(TM)s Opteron-A)
* A72
* A73
* A75
So go look at ARMâ(TM)s document, and read their white paper. As ARM claims many of their designs have this bug, Iâ(TM)m inclined to believe them.
-- Sometimes you have to turn the lights off in order to see.
How about ARMâ(TM)s own How about ARMâ(TM)s own press release and white paper?
For the record, AMDâ(TM)s Opteron-A is a Cortex A57 design, which is affected.
-- Sometimes you have to turn the lights off in order to see.
https://developer.arm.com/supp...
-- Sometimes you have to turn the lights off in order to see.
There is a nice "translation" of Intel PR speech by The Register.
Slashdot, fix the reply notifications... You won't get away with it...
Perhaps ARM's press release detailing the ten affected ARM Cortex designs may convince you?
The Opteron-A is an ARM Cortex A57 design, and is vulnerable to three of the four variants of this bug.
-- Sometimes you have to turn the lights off in order to see.
As I read it, best case, all of userland is compromised. Worst case, both userland *and* the kernel are compromised.
Weâ(TM)ve all found ourselves in the middle of a pool of shit thatâ(TM)s deeper in some places than others.
The fact AMDâ(TM)s x86 offering are in a more shallow part doesnâ(TM)t make their end of the pool any more appealing to swim in.
-- Sometimes you have to turn the lights off in order to see.
They had to do it, but it is a little... ummm...
Kill all humans...
Sorry, the article I read didn't say. It just said a specially crafted test workload.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
They are affected, but not by Meltdown but by Spectre
I am hardly spreading lies. The statement from the project Zero team explicitly calls out AMD CPU's and states it has been reproduced on them.
http://www.amd.com/en/corporat... AMD's official statement seems to confirm they are vulnerable to variant one of the attack which will be corrected in OS/vendor software. Variant 2 unlikely to be vulnerable, Variant 3 not vulnerable.
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/
I read their paper instead.
Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.
From their paper:
Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecified Xeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.
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 ]
I'm not defending Intel, I'm combating worthless misinformation that helps nobody.
Regardless of what Intel did your post seems to imply that others are not affected which they are, and by extension could prove dangerous advice for those reading your post.
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 ]
Please turn off smart punctuation in your keyboard settings. Slashdot can't cope with it.
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.
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
Nice, they link to the Linus convo about it too
"First they came for the slanderers and i said nothing."
That's a link to your mailbox...
Slashdot, fix the reply notifications... You won't get away with it...
#$&^*$# that's what happens when you have two clipboards. Here it is.
"First they came for the slanderers and i said nothing."
Thanks, and interesting, but the thread is "old", nobody will see it. You should post that to the next coming "Intel bug" story (in an hour or so?)
Slashdot, fix the reply notifications... You won't get away with it...
You will see it, and you are all that matters!
"First they came for the slanderers and i said nothing."