Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Intel Claims Security Flaw Also Impacts Non-Intel Chips, Exploits Can't Corrupt, Modify or Delete Data [Updated]
- Thread starter MacRumors
- Start date
- Sort by reaction score
Of course. They are the ones most affected. They have the most to loose. This is life and death for them.
OK so would be attackers can only read my secrets. Feel much better now, especially when said attackers can also read the secrets off AMD and ARM users
THIS!
[doublepost=1515069556][/doublepost]
It's partially patched. Last nites patch fixes 1 out of 3 errors in the processor design. Number 2 is coming. Number 3 can not be fixed. Might want to talk to Microsoft about how they are going to handle warranty. Your processor is broken and can not be fixed. If you would like to better understand this, I would read this statement by ARM https://developer.arm.com/support/security-update
Your processor is not an ARM, It's Intel,but ARM's statement is most clear and informational. Intel and AMD are using weasel words.
Last edited:
Its unlikely that they would name explicitly the A32 as this is going to upset a lot of people. Additionally the Bionic A11 is a custom chip by TSMC per Apples fabrication requirements. Its up to Apple to validate its exposure to the issue. Hence why it hasn't been explicitly named.
Per Meltdown, its unlikely that this would affect iOS as ARM chips (like ARMv8-A) don't usually provide prediction (expect for branches). See https://en.wikipedia.org/wiki/ARM_architecture#64/32-bit_architecture. Additionally the Program Counter (PC) is hidden.
If anything this will most certainly hit the MacBook and Pro lines since Apple went Intel - All the more reason to switch back to ARM in my opinion.
If your processor has PCID, almost none. And AMD has been hit with crippling processor bugs in the past, I wouldn't necessarily rule them out either.
Actually, for the 64-bit instruction set Intel 'copied' AMD.
As I noted yesterday in this thread or one of the others (getting too hard to remember where I said what now) it's very early in all of this. Yesterday I was lead to believe that ARM processors only had 1 of the 3 defects and it could not be fixed. Today I read https://developer.arm.com/support/security-update and learn that is not true. There are only certain ARM cores that are affected, they suffer from all 3 errors, and patches can exist for all 3. I'm betting the same is true for Intel. AMD is in a Better place that ether ARM and Intel. Moral of the story, Remember my advice, It's early. We do not know everything yet. Stuff is going to change. Peoples perspectives (even mine) are wrong.
Last edited:
So the Meltdown exploit can be fixed by splitting (isolating) the kernel page table away from the user ring page table. Context switching will take a bigger hit because the CPU has to dump and reload its page table cache with each context switch.
This is only necessary on intel CPUs.
So will Microsoft and linux offer AMD only versions of their server level products that do not include kernel page table isolation in the VMem code? AMD would have a lot to crow about if only intel has to suffer the ~23% to 30% hit in heavy context switching server use.
This is only necessary on intel CPUs.
So will Microsoft and linux offer AMD only versions of their server level products that do not include kernel page table isolation in the VMem code? AMD would have a lot to crow about if only intel has to suffer the ~23% to 30% hit in heavy context switching server use.
Is it early days though? I have read that they have known about this since last June.
Everyone should be outraged. This is a total industry failure. It's not one company or camp,it's all of them. This is going to cause the entire industry to have to rethink everything. To have these types of major bugs in products for up to 20 years and no one even knew? Things are going to have to be changed. Welcome to the world of the internet!
[doublepost=1515071878][/doublepost]
The AMD president has asked them to do just that. (or rather he asked the Linux developers- I expect that Microsoft had already told him no.) We will see what they do. One should note-and I know this does not make sense to most users,but many server sysadmins will not be patching at all. Their systems are in isolated networks that are not directly connected to the internet and they run only well tested and vetted software. You do not surf the web on your SQL server system. They also have very strong and expansive warranty and service agreements on them. They will be pursuing getting the servers,blades or processors replaced by the system vendor,who will take it up with Intel under their OEM warranty.
[doublepost=1515071961][/doublepost]
It's early in our understanding though. The information is under embargo until Tuesday the 9th. We will know much more in the coming days.
As a means of taking my own advice,as I have thought and learned about this over the past now 24 hours, I see two things that I did not see yesterday. One is that while this is a devastating set of bugs, the effects in practice are not going to be as bad as first thought. ARM processors can be totally patched. Between firmware, kernel changes,compiler changes and application changes. Sure that is a lot of work. But you can fix it. The slowdown from these fixes is not likely to be that great given the workloads of these systems. AMD is in better shape than Intel. Intel is not being very clear where they are, likely because they are in the worst shape and have the most affected customers. But all of the processors can be to some degree patched.
The second thing is that the effects of the patch vary by workload. We heard 5% to 30% in the beginning. 5 to 30 percent is a big difference. Turns out that 5% is the amount for consumer and most business workloads,and 30% is the amount for most server workloads. It's also been shown that these numbers might be high in both cases. Even 5% for consumer and business workloads is not nearly as bad as it sounds. If your system is 2 or 3 or even 5 % slowed, you will not notice. In servers up to 30% is a disaster. But as I noted above, Server sysadmins will not for the most part be patching and their purchasing staff will be working with the system vendors to get the bad parts out of their networks. All in all,not good at all,but not nearly as bad as it sounds at first.
Last edited:
Not sure if it was said in this thread but I read the vulnerability was inside the x86 instruction set, and if this is the case It would affect all CPUs that use x86 instructions
It is not "in the instruction set". It is in the speculative execution of instructions.
thanks for the clarification
ARM does make processors that use x86, or at least let x86 be used on them. So that is why they would be affected by it
While no one likes security flaws they are inevitable. Designers can’t predict every possible outcome nor can they predict future technology/techniques that can exploit things that weren’t possible when the designs were made. Total security that stands the test of time and expectation isn’t possible. Having to deal with code security in my workplace has taught me that. The only way to satisfy every security audit is to turn off the computer, disconnect all cables, and lock the room. Oh, and seal all the cracks and monitor it with a camera.
I think what this should do is convince people not to blindly trust any technology or software with their lives or to accept that there will always be some risk.
I think what this should do is convince people not to blindly trust any technology or software with their lives or to accept that there will always be some risk.
"Intel Security Flaw Inside."
Sometimes I miss the days of the 80186 or PowerPC chips, when we didn't have to deal with this crap.
Sometimes I miss the days of the 80186 or PowerPC chips, when we didn't have to deal with this crap.
You're right on that, but sadly I could name a few that did similar things
(goo Enron, WorldCom...)
Last edited:
I wish I had your optimism, but we're doing some language processing that chews through CPU cycles, writing massive amounts of data to queues in a high availability/replicated VM cluster, and storing the processed data in a database. In the last 24 hours, our business model has literally become "Lets gets screwed by Intel".
I think the article should be a bit clearer on the specifics of the actual vulnerabilities. They're roughly as follows:
Meltdown - Vulnerability that allows an application to read system memory it really has no business reading and so has so far only been found to affect Intel chips. Fixed by OS updates and this is actually what the Linux patches that cause those 5-30% performance hits in certain applications are trying to fix. The really bad one.
Spectre - Vulnerability that allows applications read other applications' memory they really have no business reading. Affects Intel chips universally and other manufacturer's chips in a limited fashion*. Software fixed done by updating applications and development tools (primarily compilers). Less bad, but still a serious issue.
*Google ran tests using 3 variants of a Spectre Proof-of-Concept (PoC), one non-malicious and two malicious ones. All of them worked on the tested Intel hardware while only the non-malicious one worked universally and of the two malicious ones, only one worked on one of the two tested AMD CPUs (an A8-9600 APU) and even at that only when it was run in a non-default configuration.
Meltdown - Vulnerability that allows an application to read system memory it really has no business reading and so has so far only been found to affect Intel chips. Fixed by OS updates and this is actually what the Linux patches that cause those 5-30% performance hits in certain applications are trying to fix. The really bad one.
Spectre - Vulnerability that allows applications read other applications' memory they really have no business reading. Affects Intel chips universally and other manufacturer's chips in a limited fashion*. Software fixed done by updating applications and development tools (primarily compilers). Less bad, but still a serious issue.
*Google ran tests using 3 variants of a Spectre Proof-of-Concept (PoC), one non-malicious and two malicious ones. All of them worked on the tested Intel hardware while only the non-malicious one worked universally and of the two malicious ones, only one worked on one of the two tested AMD CPUs (an A8-9600 APU) and even at that only when it was run in a non-default configuration.
Last edited:
Agree, but the longer it takes for them to respond - even a ref to the Jan 9th deadline (yes I know, PR has a few cases on its sleeves) the more obscure it looks. In the chipmakers statements there is already significant creativity around the whole truth.Until ARM have identified the A32 (or indeed any of the Apple derivatives) you're just guessing based on ignorance of the problems identified.
There's only a billion iDevices around...
Last edited:
Or just after their qtr reporting blackout dates.
[doublepost=1515076627][/doublepost]
No they didnt "copy" Intel entered into a cross-licensing agreement with AMD, licensing to AMD their patents on existing x86 techniques, and licensing from AMD their patents on techniques used in x86-64.
I noticed the same....
Last edited:
You are mischaracterizimg a11. It is a custom apple design. They designed the micro architecture, the logic, the circuits, the layout, etc. The only thing they borrowed from arm is the architecture (the instruction set). It’s not a “custom chip by TSMC per Apples fabrication requirements.” TSMC is handed an OpenAccess database which tells them the complete mask. Apple tells them where to put every polygon on every layer. TSMC didn’t design it at all, and probably had no information about what the circuits at all (they are not provided with a netlist). That’s how contract fabs work, and the reason Apple employs dozens of logic, circuit, and physical design engineers.
Apple may or may not be affected, depending on how they chose to implement the logic.