Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
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.
 
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?
 
In my opinion Apple is having some issue with transparency. Why not addressing fixes like this or actions like the battery management more openly? Many things might be good decisions or actions from a content perspective, but not well explained in the first place.
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 will be interesting to see the benchmarks from 10.13.1 and 10.13.2/10.13.3 to see the real impact on performance

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.
 
  • Like
Reactions: RandomDSdevel
Just saw some Linux benchmarks and some workloads that make lots of syscalls such as virtualization and compiling take a huge hit, while things like gaming are seemingly unaffected, I haven't felt any difference in my Macs, But I guess comprehensive benchmarking needs to be done given that it affects differently older processor families like Sandy and Ivy Bridge.

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]
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?

Found the guy that has absolutely no idea what this issue entails!!!!!
 
  • Like
Reactions: twistedpixel8
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.
 
However, programs, like games, that live in RAM and don't interact much with the kernel, will not see the performance hit.

That said, most hard hit programs are those encoding videos, processing pictures and web service servers.
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.

No they won't. You simply run benchmarks before and after the update. No need for a second identical machine.
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).
 
  • Like
Reactions: RandomDSdevel
This whole thing is just a conspiracy by Apple and Intel to get people to upgrade. Playing the long con this time.
 
  • Like
Reactions: bowmasters
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.
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.
 
  • Like
Reactions: Analog Kid
Well I can see this will be the new scapegoat for why everyone will be complaining about their slow computers.
 
What do we make of this really? I think someone should do a comparative test on handbrake or anything that solely uses CPU and only then we can tell the difference between 10.13.2 and any previous versions of macOS
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]
Just saw some Linux benchmarks and some workloads that make lots of syscalls such as virtualization and compiling take a huge hit, while things like gaming are seemingly unaffected, I haven't felt any difference in my Macs, But I guess comprehensive benchmarking needs to be done given that it affects differently older processor families like Sandy and Ivy Bridge.
I didn't know that compiling makes lots of system calls.
 
  • Like
Reactions: RandomDSdevel
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.
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.
 
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.
Yeah, exactly. There's a lot of misunderstanding about what the issue is here. The issue is reading memory. Still extremely bad.
 
  • Like
Reactions: RandomDSdevel
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.
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.
 
  • Like
Reactions: SecuritySteve
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.
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.
 
Uhm, okay ... got my new iMac 27“ today (i7).

Does that mean, that I bought an expensive machine for foto editing and video editing which is now slower than expected?
 
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.

That's awesome, please put them in this thread
[doublepost=1515016096][/doublepost]
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.
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
 
  • Like
Reactions: RandomDSdevel
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.