In order to see what this is really doing someone is going to need identical macs with different OS versions running the exact same tests in real time.
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 Memory Access Design Flaw Already Addressed by Apple in macOS 10.13.2
- Thread starter MacRumors
- Start date
- Sort by reaction score
Silly rabbits ... this isn’t a design flaw.
It’s an NSA backdoor and just like all backdoors, can be used by people whom the door was not meant for.
Remember when Wikileaks released all the companies with NSA backdoors which included Apple, and Apple had the immediate “security update” ..... yea ... wake up.
Intel has implemented backdoors for a long time in their circuitry. Intel Management Engine anyone?
It’s an NSA backdoor and just like all backdoors, can be used by people whom the door was not meant for.
Remember when Wikileaks released all the companies with NSA backdoors which included Apple, and Apple had the immediate “security update” ..... yea ... wake up.
Intel has implemented backdoors for a long time in their circuitry. Intel Management Engine anyone?
Exactly, sorry I forgot about those. Yes, VMs are actually the most hardest hit. For OS X users, that'd be running Fusion or Parallels.
Because I don’t think there is any way to explain this without their intentions being grossly misinterpreted or taken out of context by the media, and without causing undue misinformation and unnecessary panic amongst users. People are just going to latch onto the “May slow down your computer” bit to confirm their age-old conspiracy theories of forced obsolescence, despite whatever Apple says to the contrary.
It's going to be 100% dependent on what you're doing and the app you're using. Certain types of call will make some apps slower but again it's totally dependent on the individual app.
This is what most here don't seem to understand. It's not a straight drop in performance across the board. Apps that make a lot of system calls are the ones that will be most impacted.
[doublepost=1515014035][/doublepost]
Found the guy that has absolutely no idea what this issue entails!!!!!
I'm guessing my Xeon x5670s are heavily affected. So... If I'm on a single user system, does the vulnerability even matter that much for me? I don't know what in my kernel address space is more sensitive than that in my user space.
No they won't. You simply run benchmarks before and after the update. No need for a second identical machine.
This isn't necessarily true. Games it seems aren't impacted much if at all, however, it has nothing to do with residing in RAM (which games generally don't due to their size, anyways.) They're not impacted much, if at all, because they don't make many syscalls.
Likewise, video encoding likely won't see much performance impact, as well as video editing. Server type applications, as well as virtualization software and software compilers .
It really remains to be seen what sorts of performance impacts we will see. Linux is our best look right now since people can test the patches already.
Standard benchmarks will not be a good indicator of what sort of performance impact these patches have unless your workflow mimics them (it probably doesn't).
This whole thing is just a conspiracy by Apple and Intel to get people to upgrade. Playing the long con this time.
Yes. A remote attacker could leverage a separate vulnerability at the software level, (ring 3) and execute code which then leverages this vulnerability.
Edit: The significance of Kernel space compromise is that if the attacker takes over the Kernel, they can take complete control of your computer at a system level. They could encrypt your hard drive with ransomeware, or install systems that spy on your usage and report back to them without revealing their presence to the OS. Kernel level compromises are the most severe of all vulnerabilities.
On a completely not-Macintosh related side I was told that most affected are database applications with lots of hard drive access, and CPU operations are not affected at all. So HandBrake should run at full speed, if you run the database for your website on a Mac server (or any other server), there would be more of a slowdown. Just what I read but sounds reasonable.
[doublepost=1515014980][/doublepost]
I didn't know that compiling makes lots of system calls.
That's according to Intel not a possibility.
An attacker could read things they are not supposed to read, but wouldn't be able to modify anything. Of course "things they are not supposed to read" might include passwords.
For anyone interested, using the Potts-Kant benchmarks on the latest releases of both concurrent versions of Mac OS -
We're running benchmark processes concurrently with PCID disabled, employing supplementary reservoir matching sequences throughout our lab here at Duke.
The testing has just begun - so I'll be posting the results here in about an hour, for anyone interested in how their machines might be affected.
Students have been instructed to take the machines through a variety of real world tests -
So we'll be posting that, as well as the conclusive results provided by our benchmark studies - to hopefully help clear the air and provide a more balanced issuance of the possible affections of data-protected kernel-modeling architecture implications.
We're running benchmark processes concurrently with PCID disabled, employing supplementary reservoir matching sequences throughout our lab here at Duke.
The testing has just begun - so I'll be posting the results here in about an hour, for anyone interested in how their machines might be affected.
Students have been instructed to take the machines through a variety of real world tests -
So we'll be posting that, as well as the conclusive results provided by our benchmark studies - to hopefully help clear the air and provide a more balanced issuance of the possible affections of data-protected kernel-modeling architecture implications.
Yeah, exactly. There's a lot of misunderstanding about what the issue is here. The issue is reading memory. Still extremely bad.
Thats also a bit misleading. Usually 'sensitive information' in this case is memory addresses that allow for KASLR bypasses, which then allow an attacker to execute code on the kernel once the address map is known. Information Leaks often lead to Code Execution, though often it takes more than one leak to get what you need.
I’m running 10.13.2 on a 2009 iMac (yes you can!) and though it is probably coincidental and unrelated, since going from 10.13.1 I’ve had much slower wake from sleep and slower overall performance. I’d noticed it before this story and was just living with it. Who knows. I’m limping along until either I can’t upgrade or Apple upgrades the Mini to my satisfaction.
But I don't care any more about them encrypting my entire disk than I do about them encrypting my entire user directory. They can do the latter without the CPU vulnerability. The only thing besides my user is my system, which doesn't matter to me.
I can see that perspective, but nevertheless it is still a concern.
That's awesome, please put them in this thread
[doublepost=1515016096][/doublepost]
You're right is Compilebench as a whole (wich makes a lot of I/O), The linux kernel compiles in the same time in their benchmarks https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2