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.
And VMs, which I use a lot of thanks to Docker and Kubernetes.
I'm curious too, about the status of 10.12.6, as I'm not able to upgrade my OS until early March, at the earliest...
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.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.
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
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.
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 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.
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.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.
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).No they won't. You simply run benchmarks before and after the update. No need for a second identical machine.
Yes. A remote attacker could leverage a separate vulnerability at the software level, (ring 3) and execute code which then leverages this vulnerability.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.
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.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
I didn't know that compiling makes lots of system calls.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.
That's according to Intel not a possibility.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.
Yeah, exactly. There's a lot of misunderstanding about what the issue is here. The issue is reading memory. Still extremely bad.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.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.
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.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.
I can see that perspective, but nevertheless it is still a concern.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.
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.
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=2On 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.