Intel Responds To Alleged Chip Flaw, Claims Effects Won't Significantly Impact Average Users (hothardware.com) 375
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.
Video streaming? (Score:2, Interesting)
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.
Re:Video streaming? (Score:5, Interesting)
If the hit is really 30% for FUCKWIT [mail-archive.com] I wonder if there's a case to be made for a 'I know all the software on my box, don't protect me against kernel to user mode data leakage'.
You could have "--bareback" switch the user could pass into the kernel from the bootloader.
Re: (Score:3)
Re: (Score:2)
AMD bug only affect THE SAME PROCESS, unlike Intel (Score:5, Informative)
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... [blogspot.com]
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."
Re: (Score:2)
--bareback is funnier.
Re: (Score:2)
Yep, tune your I/O size (Score:3)
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.
Re: (Score:3)
I guess they won't be affected unless your application reads and writes data from/to the disk one byte at a time.
That's only one part. Reads wait on writes and I/O *to* disk forces a context switch from the CPU scheduler but that doesn't mean that the CPU isn't going to context switch when it's de/compressing a block in memory or for some other memory bound process.
Reads and writes to disk provide an opportunity to mask the CS latency in the I/O latency however there is no such opportunity in a CPU cache to system ram operation and this is where a lot of the impact will be felt. It's every task switch and that will
Re: (Score:2)
Re: (Score:3)
Yeah, he streams them with Intel(tm) Quicksync(tm).
Re: Video streaming? (Score:2)
If you're any indication, Intel spends too much on marketing and not enough on their shills...
Re: Video streaming? (Score:4, Interesting)
You must be kidding. I've been a party to class action lawsuits for the STUPIDIST shit. The latest one is for some food processor blade where I can get $15. Wanna start a pool on how much the attorney's fees end up being?
Re: (Score:3)
http://www.classactionrebates.... [classactionrebates.com] Browse, sign up, wait for your pittance.
Performance (Score:5, Interesting)
"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.
Re:Performance (Score:5, Insightful)
"Intel believes its products are the most secure in the world"
Jerry, just remember: it's not a lie if you believe it
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Just think of all the new processors they will sell when everyone's brand new processor ends up slower than sandy bridge processors that are more than 10 years old.
Re: (Score:2)
This statement nicely illustrates the difference between "belief" and "knowledge". Also refer to "delusion".
why are non broken AMD chips flagged intel? (Score:4, Insightful)
why are non broken AMD chips flagged intel?
Re: (Score:3)
From what I'm reading, it's cause the code is still in development so they basically have it turned on for everything. They plan on fixing that soon.
https://www.phoronix.com/scan.... [phoronix.com]
https://www.phoronix.com/scan.... [phoronix.com]
why is intel saying many different vendors?? (Score:2)
why is intel saying many different vendors?? When there BIG revel AMD does not have this bug.
Re: (Score:2)
Because they're lying and trying to spread the blame around so they don't look so bad?
Re: (Score:3)
Do you have a link for that assertion? I've tried a couple searches using various combinations of "arm page table kernel" and came up empty.
Re:why is intel saying many different vendors?? (Score:4, Informative)
arm64: Unmap the kernel whilst running in userspace (KAISER) [lwn.net]
ARM engineers are supplying the patches for ARM64.
KAISER is the original name of the patch set. [lwn.net]
Re: (Score:2)
Please correct me if I'm wrong, but if I'm reading this correctly, this appears to be a preventative measure in relation to Rowhammer style attacks, rather than an exploitable bug like with Intel.
Re: (Score:2)
https://www.extremetech.com/co... [extremetech.com]
I was able to find the above link, and it talks about some changes made for arm versions of the kernel as well as the x86, but I'm not seeing references to a specific bug in ARM, or any kind of analysis being reported. And I don't know enough about ARM architecture to comment (or even understand what the release notes are talking about)
Re: (Score:2)
What are you smoking? [lwn.net]
ARM engineers (not Intel's) are supplying the patches for ARM64.
Re: why is intel saying many different vendors?? (Score:5, Informative)
AMD checks privileges before it runs the code. Intel chose to optimize their branch prediction in a way that checked the privileges AFTER the code was run, but before it was written/applied. This allowed a small window for someone to read the results of that illegal instruction before it was dumped for being flagged as an exception.
I've read some info that speculates that Intel likely gained some performance by letting a lot of branch predictions run and then dumping those that are flagged after the fact instead of checking each and every one before it was run (because a lot of branches are dumped anyway for other reasons, so small price to pay to let things run and be wrong.) I don't know for sure, though. Sounds to me like they skimped on some silicon to check in hardware and put more into branch prediction.
Basically the code runs like this:
Hi, I'm a user program with user rights. I'd like to know where the super secret memory address of this part of the system is so I can read from it... and maybe even write to it later with a different exploit.
AMD: No, you're in user land, you can't see kernel land.
end of story
Intel: Oh, let me fetch that for you... Here, I've typed up a handy map of things and notes on your way around the super-secret areas... just show me your security clearance first before I hand it over.
Your malware: *glances at map, notes*
Intel: WAIT... you're in user land. You can't have this. *lights the map and notes on fire after you've already seen them*
Re: (Score:3)
You're describing Meltdown, Spectre is worse.
Spectre exploits the implementation of the CPU branch predictor to trick a high privilege process to speculatively execute some number of ROP-like gadgets. The victim process *doesn't* trip over any privilege checks.
This works because the Ivy Bridge, Haswell and Skylake indirect branch prediction state is shared between threads running on the same core. The Spectre paper claims that this also applies to AMD's Ryzen CPU's, but they didn't implement a working ex
Re: why is intel saying many different vendors?? (Score:5, Interesting)
Actually, not so quickly. Only because of Kernel-mode JIT.
Read it very carefully.
The fixes are being more careful in the bytecode verifier prior to JIT'ing (if that's even possible!), or isolating the JIT'd code into its own space, or considering eBFP bytecode loading to be as security sensitive as insmod. And... I can't see how splitting kernel space into its own page table would avoid this particular variant.
For more info about BPF, check this [cloudflare.com]. Sadly, "... Tcpdump asks the kernel to execute a BPF program within the kernel context. This might sound risky, but actually isn't." didn't take timing attacks into consideration.
They haven't demonstrated a user-mode reading kernel memory just yet. Securing a Linux box on AMD is as trivial as disabling eBPF.
However, it really uncovers a fundamental issue in all JITs allowing what should be interpreted code to read things, using timing attacks, that it should not be able to (escaping its sandbox). Hence all the references about JavaScript - similar attack allows JavaScript code to read memory outside the JavaScript world, but as far as I can tell, not read anything that the JavaScript interpreter couldn't read (although it seems to require JIT compilation). If anything, it's a general class of attacks allowing anything to read about its underlying environment.
The gotcha on Intel chips is that user-mode-x86 code can use this same timing attack on the kernel. On AMD, the timing attack is nullified because speculative reads fail before triggering cache loads.
Nice try (Score:5, Interesting)
Re: (Score:2)
Re: (Score:2)
Nice try Intel, but phoronix benchmarks prove you wrong, and show even up to 60! % loss in some loads.
They do nothing of the sort. Phoronix benchmarks hardly have anything to do with "average computer users" who provided they aren't surfing some web that is serving up coinhive malware probably don't even exceed the 40% mark on their CPU regularly.
Re: (Score:2)
They do not say anything about read (Score:5, Informative)
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.
Re: (Score:3)
They also do not say that the things that can be read (like credentials and crypto-keys) can of course be used to "corrupt, modify or delete data". A shameless lie by misdirection.
They're magic 8 ball is broken too (Score:5, Interesting)
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.
Re: (Score:2)
It worked then, it will work now. Fanbois are stupid and do not learn.
the "average computer user" my ass (Score:5, Funny)
All my users are above average.
Re: (Score:2)
All my users are above average.
Dammit, that means all mine must be below. That means more work for me...
Re: (Score:2)
I assume your users all reside in Lake Woebegone?
Re: (Score:2)
Re: (Score:3)
Some info (Score:4, Informative)
I like how they've weaseled out [intel.com] 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 [hardwareluxx.de] German [computerbase.de] websites have already tested a Windows build with a fix and found very little performance losses.
Phoronix [phoronix.com] 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).
Re:Some info (Score:4, Interesting)
The Hardwareluxx benchmarks are interesting. They certainly don't show "no" impact on gaming. In fact, what they show is more or less what you would expect to see with decreased CPU performance.
If you look at the 4K benchmarks, there is minimal-to-no impact. That's not surprising, because you would expect most modern games to be GPU-constrained at 4K, outside of some really fringe cases. Drop to 1080p, however, and you are looking at roughly a 4% or so reduction in framerates. Their test rig has a 1080 Ti - one of the best gaming cards money can buy right now and one that you would expect to be able to eat most games for breakfast at 1080p. It's not unusual for games on high-end graphics cards to hit CPU constraints at 1080p and, indeed, this is usually how sites like Eurogamer's Digital Foundry benchmark CPUs for gaming performance. By their usual standards, that 4% performance loss is pretty severe.
Will it actually affect anybody's gaming performance in the real world? Possibly. Gamers with older CPUs but a more recent graphics card (a fairly common combination) still using 1080p monitors may well see modest but still noticable performance hits based on those benchmarks. Even if it's not a huge real-world impact, it's a massive reputational blow for Intel.
Heard this before (Score:4, Insightful)
Some people never learn.
Re: (Score:3)
That's exactly what I thought of when reading the press release, too.
For those who don't remember --> https://en.wikipedia.org/wiki/... [wikipedia.org]
"[Cannot]...corrupt, modify, or delete data"?? (Score:5, Insightful)
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
Re: (Score:2)
Re: (Score:2)
Yes, but the users does not care about this. The users care whether their data is at risk of being "corrupted, modified or deleted" by this severe bug and yes, it very much is. Intel is using the tactics of lying by shameless misdirection here, apparently hoping that nobody understands what they are actually saying.
Re: (Score:2)
They're being honest, more or less. It's standard to describe what the exploit allows you to do directly.
Being able to read anything in kernel space will allow credential theft, true, but the exploit alone doesn't allow modification of data. Vulnerability reports typically describe exactly what is possible via the exploit and expect the reader to understand the implications---or to ask someone who does.
Anyone who rates vulnerabilities is going to put this into the highest risk category anyway, so it's not l
Re: (Score:3)
So the paper is 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
Looks like the Intel legal team was hard at work.. (Score:5, Interesting)
Re:Looks like the Intel legal team was hard at wor (Score:5, Informative)
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.
Just Wait A Week (Score:5, Funny)
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
Re: (Score:3)
Intel will soon be announcing a $29 CPU replacement program for qualifying customers.
...speaking of $29 to fix the battery (to speed up Apple's iPhones): Since ARM64 is also affected, every iOS device since the iPhone 5s (late 2013), as well as Android devices of similar vintage will also be seeing a slowdown from this.
Here's the hard reality: It takes roughly a year to go from tape-out (end of chip development) to a fabricated chip. That doesn't count manufacturing time, integration into designs, physical distribution, and so on.
Even if Intel (or any of the ARM64 makers) were to find and
PR lies (Score:5, Insightful)
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.
Too bad I went with AMD (Score:3, Insightful)
Now I have nothing to complain about. Get the same performance with a much lower price.
mitigated over time (Score:4, Insightful)
... 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's not a bug, it's a design decision (Score:4, Interesting)
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.
Re:It's not a bug, it's a design decision (Score:5, Insightful)
Read ex-Intel staff's opinion on why this happenes (Score:4, Interesting)
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.
Re:Read ex-Intel staff's opinion on why this happe (Score:4, Interesting)
Except this bug predates 2013. I know it's hard when facts don't conform to your bias, but you'll survive.
Re:Press the panic button (Score:5, Informative)
Re: (Score:2)
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 [lwn.net]. 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.
Re: (Score:2, Interesting)
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.
just like the Pentium bug (Score:2)
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/... [wikipedia.org]
"Publicly, Intel acknowledged the floating-point flaw, but claimed that it was not serious and would not affect most users. Intel offered to replace process
Re: (Score:3)
This has the potential of making Intel recall the floating point bug times with great fondness, nostalgia, and affection.
won't affect "average users" (Score:5, Interesting)
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.
Re: (Score:2)
The idea that your computer isn't at direct risk of modification from this is very dubious. If there's any way at all to get access to the information that lets you escalate your privs (such as if you could get a root password- I don't care if that one in particular isn't possible for some reason, the idea is the same), then you could also be dealing with data modification on top of everything else.
Re: (Score:3)
A fair chunk of the internet is mostly profitable because VMs are cheap and low commitment; and shoveling out some database backed idiocy is relatively cheap and mature. That's about the worst place you could put an "we have to implement the fix because you could break the hypervisor otherwise; but it takes a nasty bite out of databases and I/O heavy stuff" announcement.
Re: (Score:3)
It's called an Opportunity Button.
Buy a brand new Intel processor next year!
Re:Will it significantly imact me? (Score:5, Funny)
You'll now be running 1200-1600 servers depending on your workload.
Re: (Score:3, Informative)
Some ARM64 chips are affected as well actually. Citation: https://lwn.net/Articles/74039... [lwn.net]
I don't see why they would name AMD since it's unaffected however. https://lkml.org/lkml/2017/12/... [lkml.org]
Re:Many different vendors??? (Score:4, Informative)
AMD does not have the flaw. Try to keep up.
Re: (Score:2, Informative)
AMD's AMD64 chips don't have the flaw.
AMD's Opteron-A [amd.com], however, is an ARM64 chip which does have the flaw.
Re:Many different vendors??? (Score:4, Informative)
And that is relevant how? The whole discussion is 99.9...9% about AMD64.
Focus (Score:3)
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) ?
Whi
Re: (Score:3)
Re:Many different vendors??? (Score:5, Informative)
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 [lkml.org]
Re: Many different vendors??? (Score:5, Informative)
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.
Boundary violations (Score:3)
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 m
Re: (Score:3)
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.
Re: (Score:3)
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?
Re: (Score:2)
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 d
Re: (Score:2)
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. [googleblog.com]
:-/ )
Again, if I'm not clicking ads and opening strange files, I'm really only worried about privilege escalation (Like Intel Management Engine
Re: (Score:3)
Re: (Score:2)
Seriously? [osvdb.org]
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".
Re: (Score:2)
Re:Can we pause the Panic Parade, please? (Score:4, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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... [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.
Re: (Score:2)
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
Re: (Score:2)
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 [microsoft.com]
, so we probably won't get any details until at least then.
I imagine Linux 4.15 will be released around the same timeframe.
Re: (Score:3)
Re:Not just Intel, also AMD and ARM (Score:5, Insightful)
Based on other comments above, there is a fair chance you misunderstand the nature of the bug. It is reported that AMD validates requests for speculative execution before executing them, and Intel validates them afterwards. The bug is supposedly that it's possible to read the results of the speculative execution before the Intel chip notices that they were improperly executed. If that is so, then the AMD chips do *not* have this particular bug.
Re: (Score:3)
Look at the blog post I linked.
You mean the one that says "AMD provided the following link: http://www.amd.com/en/corporate/speculative-execution [amd.com]? It contains the following in a table:
Re: (Score:3)
Basically, this isn't an implementation bug, or even a design flaw... it's an architectural flaw, present in all modern CPUs.
Except those from AMD [barrons.com].
This is incredibly huge. To a first approximation, all computers are broken.
All computers made by Intel, anyway. They have always been shitty at branch prediction. That's why the P4 sucked so hard; it had a long pipeline and their branch predictor wasn't up to snuff, and branch prediction happened fairly early in the pipeline so you had to throw away many cycles when it mispredicted. Intel addressed this inadequacy by playing fast and loose with OoO to get a performance improvement, and now there's a vulnerability. This is just more typical incompetence from