No MDS-style attack patching for older MacPros - now what?

[tsialex]

I just downgraded to 142.0.0.0.0 and redid all the SMTDisable process again to see if you can disable Hyper-threading with past BootROM versions, @Raunien tested 138.0.0.0.0 and @TzunamiOSX tested 140.0.0.0.0.

This is the result:

So, you can only disable Hyper-Threading with BootROM 144.0.0.0.0

 

[Raunien]

So, you can only disable Hyper-Threading with BootROM 144.0.0.0.0

Thanks for checking. Much appreciated.

 

[thekev]

I was checking VMWare Fusion support documentation for the security corrections and VMWare published a table of the performance hit for ESXi on the support article: VMware Performance Impact Statement for ‘L1 Terminal Fault - VMM’ (L1TF - VMM) mitigations: CVE-2018-3646 (55767)

"this scheduler provides the Hyper-Threading-aware mitigation by scheduling on only one Hyper-Thread of a Hyper-Thread-enabled core."

It's a 22 to 32% performance hit to mitigate side channel attacks:

View attachment 837504

That is very interesting, but it's still quite context specific. The link mentions somewhat of a high level strategy taken here in scheduling resources from the view of the hypervisor. 32% was the loss on a host with an OLTP database. It's likely that the use of hyperthreading is used to hide latency incurred by fetches from disk or main memory, since each core can run up to 2 threads without the need to explicitly swap them.

Mitigation of the Concurrent-context attack vector requires enabling the ESXi Side-Channel-Aware Scheduler, also referred to as the ESXi SCA Scheduler. Currently, this scheduler provides the Hyper-Threading-aware mitigation by scheduling on only one Hyper-Thread of a Hyper-Thread-enabled core.

I'm actually curious what Mixed Workload, Java, and VDI entail. The latter 2 are still server side workloads.

They also mention the following.

While each application has its own characteristics, we saw a similar pattern across different types of applications. The more usable host CPU capacity available prior to mitigation, the less the performance impact was after mitigation.

They also mention that they 32% number comes from a model that is running at 90% of cpu capacity. This is quite high for something that isn't just running long arithmetic calculations. Setups that run largely compute bound arithmetic heavy tasks may not benefit much from hyperthreading to the point where they may have disabled it anyway. You can see export specifications for a number of cpus here. If we go by their numbers and consider a strongly compute bound problem like gemm and intel's stated numbers for load throughput even on skylake and later, you can in fact saturate or mostly saturate peak bandwidth without scheduling as 1 physical core as 2 logical ones.

Given about a 4 cycle hit time in L1 and a claimed load bandwidth of 4 x 256 bit loads per cycle, you might end up with a little spare L1 bandwidth. I suspect though that this makes it easier to mostly saturate the cpu on classically memory bound problems, an example being elementwise multiplication. Inner loop here should take about 12 cycles (edit: on skylake), judging by intel's numbers, if things hit in L1. I haven't timed it. Using their peak bandwidth numbers on loads, we can't fully hide load latency here and may have a couple delay cycles at the beginning. This assumes they don't overlap with consecutive loop iterations, since the stores encounter the same thing and on aligned memory, we don't have conflicts or minor latency penalties due to store forwarding.

This is still a historically memory bound problem compared to something like matrix multiplication, but I don't see a lot of benefit to running 2 threads per core here when compared to the test environment used by VMWare. They're quite different, but large sections of this kind of code are still common enough to use it as a minimal example.

 

[Sharky II]

I run huge projects in Logic X and cannot afford to disable Hyperthreading. 'Turning off the internet' is impractical here. Not sure how this will affect users in my position, then.

Forced to an iMac/newer Mac Pro?

 

[tsialex]

I run huge projects in Logic X and cannot afford to disable Hyperthreading. 'Turning off the internet' is impractical here. Not sure how this will affect users in my position, then.

Forced to an iMac/newer Mac Pro?

Hyper-Threading is not useful for every workload. Simplifying to the extreme, Hyper-Threading it's a virtual resource that was designed to keep the processor working when it have to wait for something. A lot of realtime applications runs worse with Hyper-Threading enabled.

Logic X is not the type of workload that seems appropriated for Hyper-Threading, did you ever tested if you can use the same number of tracks with Hyper-Threading disabled?

Apple even indirectly recommends that you use only processing threads as you have real cores. https://support.apple.com/en-us/HT202993

 

[crjackson2134]

For most people, SMT being disabled will be almost imperceptible, but doing that is a serious problem for people that have to do CPU intensive tasks like compiling and encoding video or run heavy multithreaded apps. No one that need SMT will want to lose the speed up.

I’m aware that there’s at least one app that can switch off/on SMT on the fly. So why not switch it off when not needed and just doing causal activities, then switch it back on when doing CPU intensive tasks?

That’s something “I” could live with if it comes down to it. Personally, I’m not particularly concerned at the moment. I use only Safari when browsing and I don’t indulge myself at questionable or dodgy websites. Since I’m not an enterprise level consumer, I’m going to leave it as is for now. There’s no need for the home/causal user to become worked up at the present time. I’m aware this could change in the future, and I’ll adjust my strategies as needed at that time. For now, I’m standing pat with the default settings.

Just my worthless 2¢

 

[tsialex]

I’m aware that there’s at least one app that can switch off/on SMT on the fly. So why not switch it off when not needed and just doing causal activities, then switch it back on when doing CPU intensive tasks?

That’s something “I” could live with if it comes down to it. Personally, I’m not particularly concerned at the moment. I use only Safari when browsing and I don’t indulge myself at questionable or dodgy websites. Since I’m not an enterprise level consumer, I’m going to leave it as is for now. There’s no need for the home/causal user to become worked up at the present time. I’m aware this could change in the future, and I’ll adjust my strategies as need at that time. For now, I’m standing pat with the default settings.

Just my worthless 2¢

It's not understood yet how this apps like CPU-Setter do it. Apple solution uses the firmware to do it, so the kernel already boots with Hyper-Threading disabled.

For now, we need to understand even if the way these apps work really mitigates the MDS attacks.

 

[Slash-2CPU]

Most users are under the "Wait, what?" reply and do not know anything about it. Terminal commands are beyond the typical user's ability or understanding.

Anyone who follows the normal "Update" upgrade path will not get 144.0.0.0.0 firmware to allow SMT disable. Only if you download and run a full installer AND to the power button firmware process will 144.0.0.0.0 get installed.

There will be many older Macs out there with SMT enabled. We'll know soon if that's a big problem or not. Those with 144.0.0.0.0 or later and SMT disabled will be in the minority.

 

[tsialex]

Most users are under the "Wait, what?" reply and do not know anything about it. Terminal commands are beyond the typical user's ability or understanding.

There will be many older Macs out there with SMT enabled. We'll know soon if that's a big problem or not.

I don't need much imagination to see a scenario that Apple will disable SMT by default in the firmware and then the user enables it if needed, exactly the inverse of today. If someone develops a MDS attack that propagates via ad-networks or something similar, I see Apple doing it.

 

[bookemdano]

I don't need much imagination to see a scenario that Apple will disable SMT by default in the firmware and then the user enables it if needed, exactly the inverse of today. If someone develops a MDS attack that propagates via ad-networks or something similar, I see Apple doing it.

Yes, but even if they do that, only some subset of cMP users will get the firmware--maybe only 50% or even less. Mojave updates delivered through the built-in update mechanism install without requiring a firmware update (I don't know if Apple can change that, or if they would if they can). Pretty much the only way to force a firmware update would be with macOS 10.15.

I bet Apple really regrets the firmware update mechanism they implemented for the cMP. When it comes to mitigating huge vulnerabilities like this, they can hardly impose it even if they want to since the procedure to perform the upgrade requires manual intervention by the end user (and oftentimes doesn't work even if the user follows the procedure). All other currently supported Macs have transparent, automatic fw updates.

Yet another reason I think Apple may kill off the venerable old cheese grater this year. Up until this vulnerability was discovered/disclosed I was very bullish on the cMP making the cut for one final year of macOS updates. But with the current situation I think the chances are quite high that they put it out to pasture for good.

I wonder if there is any route for end users to persuade Intel to change their mind about updating microcode for Westmere. Not just cMP users but there are lots of workstations and servers still in use with those CPUs. Not only that, but from what I've read, disabling HT on those processors doesn't fully address the problem since AES-NI is another vector and to my knowledge all Westmere CPUs incorporate AES-NI.

 

[tsialex]

Yes, but even if they do that, only some subset of cMP users will get the firmware--maybe only 50% or even less. Mojave updates delivered through the built-in update mechanism install without requiring a firmware update (I don't know if Apple can change that, or if they would if they can). Pretty much the only way to force a firmware update would be with macOS 10.15.

I bet Apple really regrets the firmware update mechanism they implemented for the cMP. When it comes to mitigating huge vulnerabilities like this, they can hardly impose it even if they want to since the procedure to perform the upgrade requires manual intervention by the end user (and oftentimes doesn't work even if the user follows the procedure). All other currently supported Macs have transparent, automatic fw updates.

Yet another reason I think Apple may kill off the venerable old cheese grater this year. Up until this vulnerability was discovered/disclosed I was very bullish on the cMP making the cut for one final year of macOS updates. But with the current situation I think the chances are quite high that they put it out to pasture for good.

I wonder if there is any route for end users to persuade Intel to change their mind about updating microcode for Westmere. Not just cMP users but there are lots of workstations and servers still in use with those CPUs. Not only that, but from what I've read, disabling HT on those processors doesn't fully address the problem since AES-NI is another vector and to my knowledge all Westmere CPUs incorporate AES-NI.

I agree with what you say, but I was talking about all Macs and not just MP5,1. AFAIK, practically all Macs have processors that support SMT except some really entry level iMacs with i3 and the models with i5 processors.

If MDS attacks become a common problem, Apple will have to implement SMT not enabled as default state in the firmware. If you are a user that need HT, you enable it, if not, it’s already disabled. This is a imagined scenario where the security comes first, maybe we will see it happening.

 

[MarkC426]

Hyper-Threading is not useful for every workload. Simplifying to the extreme, Hyper-Threading it's a virtual resource that was designed to keep the processor working when it have to wait for something. A lot of realtime applications runs worse with Hyper-Threading enabled.

Logic X is not the type of workload that seems appropriated for Hyper-Threading, did you ever tested if you can use the same number of tracks with Hyper-Threading disabled?

Apple even indirectly recommends that you use only processing threads as you have real cores. https://support.apple.com/en-us/HT202993

I havn’t tried any animations yet, but rendering a single frame with HT off took 17% longer.....which is acceptable for me.

 

[tsialex]

I havn’t tried any animations yet, but rendering a single frame with HT off took 17% longer.....which is acceptable for me.

Virtualization, video encoding, compiling are workloads that usually benefits with SMT, but not all apps/encoders/compilers benefits with the same way. Video render probably benefits from SMT too.

 

[Sharky II]

Hyper-Threading is not useful for every workload. Simplifying to the extreme, Hyper-Threading it's a virtual resource that was designed to keep the processor working when it have to wait for something. A lot of realtime applications runs worse with Hyper-Threading enabled.

Logic X is not the type of workload that seems appropriated for Hyper-Threading, did you ever tested if you can use the same number of tracks with Hyper-Threading disabled?

Apple even indirectly recommends that you use only processing threads as you have real cores. https://support.apple.com/en-us/HT202993

Hi,

Logic X allows you to set the threads to use 12 or to use automatic or stipulate 24 (and numbers in-between). I am assuming that at 12 threads, it is not using hyper threading, however.

Just ran a test @ 96KHz:

12 Cores/threads: 126 tracks
24 threads: 177 tracks

Big difference for my workflow and usage

 

[tsialex]

Hi,

Logic X allows you to set the threads to use 12 or to use automatic or stipulate 24 (and numbers in-between). I am assuming that at 12 threads, it is not using hyper threading, however.

Just ran a test @ 96KHz:

12 Cores/threads: 126 tracks
24 threads: 177 tracks

Big difference for my workflow and usage

That is a estimative, no? When using all 177 tracks you don't have contention issues? The way Intel implemented SMT using virtual cores varies gain/benefit wildly with your workload.

 

[Sharky II]

I used the standard logic x benchmark. I don't know what you mean by estimative really - it tells me that I can run 50 more tracks in this benchmark than without.

Sorry, I also don’t know what contention issues means

I think it’s generally accepted that in the case of such a heavily multithreaded audio app, hyper threading helps a lot (hence setting CPU threading to automatic sets it to 24 in Logic)

 

[handheldgames]

That is a estimative, no? When using all 177 tracks you don't have contention issues? The way Intel implemented SMT using virtual cores varies gain/benefit wildly with your workload.

Could you post a geekbench score for your dual x5680 with and without hyper threading? It would be good to see a side by side comparison on a Mac Pro.

 

[Demigod Mac]

Most, if not all, in this thread probably don't need to disable hyperthreading. Zombieload is not some innovative new way to deliver an attack payload to a machine, it's just a new trick malicious code can do if it runs on your machine. So the steps for preventing a zombieload attack are the same as any other piece of malware: don't let your machine get exposed to malicious code in the first place. Make sure your browser is up to date, use an adblock plugin to protect against malvertising attacks, don't visit shady websites, carefully vet software download sources, enable the firewall on your router, etc. News articles make these CPU vulnerabilities seem a lot scarier to home users than they really are, as if having a vulnerable machine means it's going to get compromised in 2 seconds of being plugged into internet . That is not necessarily true or even likely.

Let's consider a scenario where you actually do get hit with a real zombieload attack, but you disabled HT on your Mac so you're 100% immune and okay, right? Well, no - if it got that far, there's probably still malicious code running on your machine. At that point I would just reformat and do a clean macOS install.

 

[bsbeamer]

Plan to run some tests with HT disabled with Adobe video software in the next week or two. On authentic mid-2012 MP5,1 which technically is not impacted according to Apple support documentation. Also opening a support request with Apple using authentic OEM single CPU tray and specifically recommended Sapphire Pulse RX580 8GB to hopefully learn more about proper mitigation and/or vulnerability for mid-2012 machines.

Unfortunately, anyone who ever works with serious or semi-serious corporate IT will be SOL with MP5,1's that are not patched/mitigated in the coming months. Initially that seems to be entirely Intel's fault. This MAY force me to retire my personal machine for most paying client work before EOY 2019, but will see what tests reveal. Constantly pulling ethernet cables, disconnecting internet/WiFI, and resetting NVRAM to swap back does not seem like a viable long-term solution.

Even more of a reason Apple SHOULD be direct with plans for the MP7,1 very soon. Many of the remaining Mac towers in client offices will likely be shutdown before 2020 after this news. There are not a ton of holdouts left and this may force even more to another platform. Guess we'll wait and see...

 

[2984839]

I’ve switched off hyper threading and go on using my old Mac pros

This is the best way to deal with it.
[doublepost=1558277090][/doublepost]

Most, if not all, in this thread probably don't need to disable hyperthreading. Zombieload is not some innovative new way to deliver an attack payload to a machine, it's just a new trick malicious code can do if it runs on your machine. So the steps for preventing a zombieload attack are the same as any other piece of malware: don't let your machine get exposed to malicious code in the first place. Make sure your browser is up to date, use an adblock plugin to protect against malvertising attacks, don't visit shady websites, carefully vet software download sources, enable the firewall on your router, etc. News articles make these CPU vulnerabilities seem a lot scarier to home users than they really are, as if having a vulnerable machine means it's going to get compromised in 2 seconds of being plugged into internet . That is not necessarily true or even likely.

Let's consider a scenario where you actually do get hit with a real zombieload attack, but you disabled HT on your Mac so you're 100% immune and okay, right? Well, no - if it got that far, there's probably still malicious code running on your machine. At that point I would just reformat and do a clean macOS install.

Any time you visit a website, you are allowing someone else to run code on your machine. It is possible to execute Spectre/Meltdown attacks through the web browser: https://www.tomshardware.com/news/meltdown-spectre-exploit-browser-javascript,36221.html

Mitigations are being rolled out by browser vendors, but with all the new variations of the attacks coming out it is still quite likely that you remain vulnerable.

 

[flaubert]

Yet another reason I think Apple may kill off the venerable old cheese grater this year. Up until this vulnerability was discovered/disclosed I was very bullish on the cMP making the cut for one final year of macOS updates. But with the current situation I think the chances are quite high that they put it out to pasture for good.

I wonder if there is any route for end users to persuade Intel to change their mind about updating microcode for Westmere. Not just cMP users but there are lots of workstations and servers still in use with those CPUs. Not only that, but from what I've read, disabling HT on those processors doesn't fully address the problem since AES-NI is another vector and to my knowledge all Westmere CPUs incorporate AES-NI.

Sadly, I agree with you on the prospects for continued support of our classic Mac Pros. I doubt that merely complaining to Intel or Apple would have much effect, though I certainly plan to communicate to both. I wonder if some form of crowdfunding would have an effect - the style where funds are pledged but not taken until some goal or agreement is reached? In this case, the funding would be contingent on Intel agreeing to provide microcode support.

 

[bookemdano]

Sadly, I agree with you on the prospects for continued support of our classic Mac Pros. I doubt that merely complaining to Intel or Apple would have much effect, though I certainly plan to communicate to both. I wonder if some form of crowdfunding would have an effect - the style where funds are pledged but not taken until some goal or agreement is reached? In this case, the funding would be contingent on Intel agreeing to provide microcode support.

I agree that we probably don't have much of an avenue here. Folks who can make the greatest case are authentic 2012 5,1 owners. But even so, it probably more depends on whether any large organizations (corps, education, government) still have a large fleet of them--they're probably the ones with the most clout. In fact those customers may have been the reason the 5,1 has gotten the attention it has from Apple in the last year. Big orgs tend not to hold onto computers long term. So Intel's calculation may be that many of them are ready to be replaced anyway.

From Apple's perspective, I think this mainly hinges on the status of the 7,1/mMP. If they are far enough along in the development cycle such that they can announce it this year then they have little incentive to support the 5,1 for 10.15. And this MDS stuff from Intel may have given Apple the incentive to speed things up such that they can make an announcement soon. WWDC would be ideal because that's when they will formally announce 10.15 and detail its compatibility list. So we will probably know our fate in about two weeks.

Man, the highs and lows of being a cMP5,1 owner over the last 12 months have been astonishing!

 

[flaubert]

Ha, yes, the highs and lows... I’ve been in negotiation this week to buy a backup single-processor cMP 5,1 in case anything fails on my main machine. Price is $300 with 16GB ram, so it seemed like a good deal; now with all the uncertainty around continued support I’m kind of wavering on the purchase...

 

[bookemdano]

Well, chances are still very good that 10.15 will run on cMP5,1 (and of course 4,1>5,1) without much if any compromise. All the leaks so far about it are that it's very much an "evolution" release that will mainly flesh out some of the half-baked technologies that debuted in Mojave (like High Sierra was to Sierra).

So unless Apple does something drastic, any block on the cMP5,1 should be easy for people like dosdude1 to circumvent.

But yeah, if you're only interested in official support, then I would say right now is a very bad time to buy a 5,1.

 

[tsialex]

I wonder if some form of crowdfunding would have an effect - the style where funds are pledged but not taken until some goal or agreement is reached? In this case, the funding would be contingent on Intel agreeing to provide microcode support.

I understand the financial motives for Intel not making microcodes updates for Nehalem/Westmere. If we can't pressure Intel to backtrack this, we will pay for it via crowdfunding?

Let's think a little with the Pandora's box that paying for Intel to correct security flaws will open. Every system manufacturer will start to demand pay for security updates and this is a scenario that makes every user hostage. Some of them already do it indirectly with support contracts and will be very emboldened by this. Your router has a flaw? Wireless camera? Remote controlled door bell? Home automation system? Pay to get the security corrections.

What we need is rules that clearly define support window. It's a mature industry, Intel will be 51 in a little over a month. No one changes computers every year to get 5% performance gains. Not even gamers are doing it anymore. A mainstream CPU should have X years support or something a long it.

Microsoft and Apple should provide security updates at least for the same time. Microsoft is a lot better than Apple with long term maintenance, Apple security support window is just 3 years and it's ridiculous. If you have a specific need for a macOS release and the three year support is over you are on your own. This need to be changed.