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."
Nice try Intel, but phoronix benchmarks prove you wrong, and show even up to 60! % loss in some loads.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.