Intel Memory Access Design Flaw Already Addressed by Apple in macOS 10.13.2

[Mad Mac Maniac]

According to The Register, which first shared details on the vulnerability, Windows and Linux machines will see a 5 to 30 percent slowdown once a fix is in place. It appears Macs may not be hit as heavily, as no noticeable performance slowdowns have been reported since the launch of macOS 10.13.2.

Ionescu also says that performance drop on a system with PCID (Process-Context Identifiers), available on most modern Macs, is "minimal," so most users may not see an impact on day-to-day Mac usage.

Article Link: Intel Memory Access Design Flaw Already Addressed by Apple in macOS 10.13.2

Wow, if Windows sees a 30% slowdown and Macs have a negligible impact that would really be something. I don't know if that would be good design/coding on Apple's part or just plain luck. Definitely good news for my 2013 MBA which I am planning on keeping as long as I can. I'm shooting for 2023!

 

[djlythium]

So, what does the ‘double map’ do anyway?

 

[xgman]

There is a new 10.13.3 beta ver out today for devs.

 

[belvdr]

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

This has nothing to do with CPU utilization. Rather, you will see a performance penalty when an applications makes system calls, such as to files or network access. Essentially it occurs when ring 3 needs to access something at the more privileged ring 0.

 

[noxivs]

A very good read on the situation. http://www.tomshardware.com/news/intel-bug-performance-loss-windows,36208.html

 

[SecuritySteve]

So, what does the ‘double map’ do anyway?

Essentially, the vulnerability resides in Intel Processors ability to 'speculate' as to what code needs to be executed next, and execute it in advance so that it is cached and ready for the real execution. The vulnerability allows for the security context of that code execution to escalate from user land (referred to as ring 3) to kernel land (referred to as ring 0). The significance is that the Kernel memory houses sensitive information on the system that, once read, can be leveraged to escalate privileges. Double mapping adds an additional buffer between the kernel and user, which mitigates but doesn't completely solve the vulnerability. That is why additional 'tweaks' are necessary in 10.13.3.

 

[MacsRgr8]

Didn't see any performance drop on my Macs.

Same here.

 

[juanmj93]

Alex Ionescu https://twitter.com/aionescu?ref_sr.../01/03/intel-design-flaw-fixed-macos-10-13-2/ was the first to report the patch was already implemented on MacOS 10.3.2, however seems to suggest more changes in the beta of 10.3.3, so maybe the performance differences are still not "settled"

 

[iPhysicist]

Safari seems snappier.

This was long overdue!

 

[belvdr]

Essentially, the vulnerability resides in Intel Processors ability to 'speculate' as to what code needs to be executed next, and execute it in advance so that it is cached and ready for the real execution.

Was it confirmed that feature causes this? I didn’t get a chance to keep up with this today and last I read it was speculative whether that feature was the cause.

 

[noxivs]

Essentially it occurs when ring 3 needs to access something at the more privileged ring 0.

So it is only supposed to affect the file browsing performance on the OS? This may only be an issue with server grade workloads then. Hardly anything to do with in-application workloads?

 

[PG(Austin)]

What about El Capitan and Sierra?

My thoughts exactly.

 

[jav6454]

Didn't see any performance drop on my Macs.

The performance hit is when a program continuously access kernel information (such as network, I/O from SSD/HDD or other add on cards).

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.

 

[belvdr]

So it is only supposed to affect the file browsing performance on the OS? This may only be an issue with server grade workloads then. Hardly anything to do with in-application workloads?

Or any other device access really. At this point, I would consider any workload potentially impacted until tested. FWIW, I would not expect casual desktop users or many power users to notice any change.

 

[SecuritySteve]

Was it confirmed that feature causes this? I didn’t get a chance to keep up with this today and last I read it was speculative whether that feature was the cause.

Judging from the Linux kernel code commits, and the double buffer solution, it's almost certainly the case.

 

[krell100]

Does the flaw affect Intel Xeon processors?

 

[juanmj93]

Also (not sure if reposting) Ars technica has a pretty cool explanation of the issue here https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/

 

[longofest]

My MBP and Mac Mini are both 2012 models.

It would obviously depend on what kind of workload you run. I've seen some people say that IOP heavy workloads could suffer 20-30% (or more)

 

[SecuritySteve]

Does the flaw affect Intel Xeon processors?

Yes. All processors Skylake and back are affected. (Supposedly).

 

[nutmac]

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.

Intel has imposed an embargo on discussing this issue.

 

[nt5672]

Ah how nice to hear Apple is ahead of this one. Would be refreshing if this was a turn around of a pretty rocky 2017 as far as software hardness goes.

Maybe they are and maybe not. They did not say it was completely solved and we don't know the extent of the slowdown with the final solution. And it appears that the final solution is coming after linux (an open source volunteer effort) released their solution. So I don't see any positive here at all, other than the fact that Apple did not deny it as they have in the past with other problems. But with the publicity, they had no choice.

 

[SeaFox]

So quick that it happened in the past! I like this new time-bending Apple.

 

[SecuritySteve]

Maybe they are and maybe not. They did not say it was completely solved and we don't know the extent of the slowdown with the final solution. And it appears that the final solution is coming after linux (an open source volunteer effort) released their solution. So I don't see any positive here at all, other than the fact that Apple did not deny it as they have in the past with other problems. But with the publicity, they had no choice.

You're misunderstanding the issue. The solution to the Linux kernel and the solution Apple has released here are different, and Apple released theirs first. The issue is not completely fixed with Apple's solution, but in principal the solution could be complete with a few tweaks. In the mean time, most users are almost completely safe and haven't noticed a slowdown. I'd say score one for Apple.

 

[thejadedmonkey]

The performance hit is when a program continuously access kernel information (such as network, I/O from SSD/HDD or other add on cards).

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.

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...

 

[AppleInLVX]

Same here.

FWIW, I didn't notice a difference either.