MP 1,1-5,1 Mac Pro 5,1 MDS vulnerability information thread

[MisterAndrew]

This was first reported in the BootROM thread. Here is a dedicated thread to compile the information into one place. This is a WikiPost so anyone with the proper credentials may edit it.

Apple links:
Additional mitigations for speculative execution vulnerabilities in Intel CPUs
How to enable full mitigation for Microarchitectural Data Sampling (MDS) vulnerabilities

Intel links:
Side Channel Vulnerability MDS
Intel Microarchitectural Data Sampling Advisory
Deep Dive: Intel Analysis of Microarchitectural Data Sampling
May 14, 2019 Microcode Revision Guidance

Other links:
ZombieLoad Attack
RIDL and Fallout: MDS attacks

Papers:
Zombieload
Fallout
RIDL

Types of MDS attacks:
CVE-2018-12126 (Fallout): Microarchitectural Store Buffer Data Sampling (MSBDS)
CVE-2018-12127: Microarchitectural Load Port Data Sampling (MLPDS)
CVE-2018-12130 (Zombieload / Rogue In-Flight Data Load (RIDL)): Microarchitectural Fill Buffer Data Sampling (MFBDS)
CVE-2019-11091: Microarchitectural Data Sampling Uncacheable Memory (MDSUM)

Macs unsupported by the mitigations due to lack of microcode updates from Intel:
MacBook (13-inch, Late 2009)
MacBook (13-inch, Mid 2010)
MacBook Air (13-inch, Late 2010)
MacBook Air (11-inch, Late 2010)
MacBook Pro (17-inch, Mid 2010)
MacBook Pro (15-inch, Mid 2010)
MacBook Pro (13-inch, Mid 2010)
iMac (21.5-inch, Late 2009)
iMac (27-inch, Late 2009)
iMac (21.5-inch, Mid 2010)
iMac (27-inch, Mid 2010)
Mac mini (Mid 2010)
Mac Pro (Early 2009)
Mac Pro (Mid 2010)
Mac Pro (Mid 2012)

Vulnerability status for these machines with Hyper threading (SMT) disabled: Unclear

Conflicting information from Apple and Intel:
Apple: "Full mitigation requires using the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology."
Intel: "Intel is not recommending that users disable Intel® Hyper threading. It’s important to understand that doing so does not alone provide protection against MDS"

But is it conflicting? Perhaps not. Here’s why:
Disabling SMT (Hyper Threading) is Apple’s method of “full mitigation,” but Apple lists these machines as not supporting the mitigations due to lack of microcode updates. It may be that disabling SMT provides full mitigation for machines that are receiving microcode updates, but disabling SMT on these machines doesn’t provide full mitigation because Intel states that disabling SMT alone does not provide protection. In the 'Deep Dive' article linked above Intel also states, "some processors may only enumerate MD_CLEAR after microcode updates," which means the microcode updates are necessary for buffer overwriting. There are software instruction sequences that may be used to overwrite buffers, but it isn't clear if that is something the OS will do automatically or if it needs to be done manually.

Apple's full mitigation solution is to type the following commands in Terminal with the machine booted into Recovery mode:
nvram boot-args="cwae=2" (additional CPU instruction? What does this do?)
nvram SMTDisable=%01 (disables simultaneous multithreading)

 

[tsialex]

I just noticed one stupid error on the Apple support article, there’s no late-2010 Mac Pro and they causally forgot the early-2009 one:

 

[MisterAndrew]

To be clear, for myself and others, these Macs are not vulnerable after disabling Hyper-Threading Technology?

 

[tsialex]

To be clear, for myself and others, these Macs are not vulnerable after disabling Hyper-Threading Technology?

ZombieLoad paper, on the conclusion, talks that the ultimate mitigation is disabling hyper-threading.

Seems we need some time to digest everything and know what is vulnerable or not. Nehalem Xeon processors seems to be vulnerable to one bug, the one caused by hyper-threading, and Westmere to two of the four divulged yesterday, hyper-threading and AES-NI.

The other papers didn’t made statements about mitigation, so I’m not exactly sure about that.

 

[tsialex]

Intel published kernel code to mitigate the side channel vulnerabilities cleaning buffers even for Nehalem.

One thing intrigued me, why they won't issue new microcode support for Nehalem and Westmere since they are issuing new microcodes versions for Sandy Bridge and Ivy Bridge?!?

 

[bookemdano]

I just noticed one stupid error on the Apple support article, there’s no late-2010 Mac Pro and they causally forgot the early-2009 one:
View attachment 837186

I don't think omission of the 2009 is an error. It mentions that the following list of Macs "may receive updates in macOS Mojave, High Sierra or Sierra". The 2009/MacPro4,1 is not compatible with anything past El Capitan (which, evidently will not receive any mitigation at all for these vulnerabilities).

What probably is an error is that they didn't specifically mention the 2012 Mac Pro, which is affected the same as the 2010.

 

[tsialex]

I don't think omission of the 2009 is an error. It mentions that the following list of Macs "may receive updates in macOS Mojave, High Sierra or Sierra". The 2009/MacPro4,1 is not compatible with anything past El Capitan (which, evidently will not receive any mitigation at all for these vulnerabilities).

What probably is an error is that they didn't specifically mention the 2012 Mac Pro, which is affected the same as the 2010.

late-2010 Mac Pro?!?

 

[bookemdano]

late-2010 Mac Pro?!?

I didn't address that part of your post. Calling it "late 2010" is indeed a stupid error, albeit totally inconsequential as there was only one Mac Pro release during 2010.

What I was addressing was the second part where you said that they "casually forgot" the early 2009. I don't think that was an error, since it's only compatible with El Capitan and earlier OS X releases--none of which will receive any patching at all for the MDS vulnerabilities.

 

[tsialex]

What I was addressing was the second part where you said that they "casually forgot" the early 2009. I don't think that was an error, since it's only compatible with El Capitan and earlier OS X releases--none of which will receive any patching at all for the MDS vulnerabilities.

Yes, they don't support MP4,1 anymore since El Capitan and since only Sierra still get security updates, your statement makes sense.

Seems they just got the Sierra supported Macs and made that list showing the ones that Intel won't issue microcode updates.

 

[Lycestra]

Even if the OS isn't obsolete, 2009 Mac Pro's are considered obsolete officially, so I'd think they're off official radar. Doesn't stop me from using mine to run Mojave (thanks for all the continuing info tsialex!)

 

[bookemdano]

I've been (and still am to some degree) bullish on the MacPro5,1 getting official compatibility with macOS 10.15--was even more so last week with the leaks that 10.15 is mainly going to be about fleshing out the new technologies introduced in 10.14 (Marzipan apps most especially).

But this damn Intel sh*tshow could force Apple's hand here. If Intel won't update the microcode for any processor used in any cMP then I think there's a strong chance Apple will view the platform as tainted and won't want to encourage continued use of it by gracing it with another macOS release. They might drop it just to encourage cMP owners (of which the vast majority are likely in corporate & educational use--large targets for exploits) to move to a model that is receiving a microcode fix.

Especially if Apple can get the mMP out in early 2020 (still a huge "if" at this point).

I'm quite optimistic any block Apple might implement would be easy to work around for dosdude1 et al. So unofficially we can almost definitely continue on. But it still sucks to see Intel throw us to the curb, considering how many Westmere-era Xeons are still in active use... not just in the cMP but in plenty of other servers and workstations. I sure hope they are persuaded to reconsider their decision not to issue microcode for our CPUs.

 

[tsialex]

Disabling Hyper-Threading works perfectly with 10.13.6 + Security Update 2019-003:

This is from Recovery, grabbed manually via screencapture command:

Now, after Hyper-Threading disabling and shutdown:

system_profiler SPHardwareDataType; sysctl machdep.cpu.brand_string; sysctl hw.physicalcpu hw.logicalcpu

Edit:

144.0.0.0.0 is a pre-requisite for SMTDisable plus 10.12.6 + 2019-003, or 10.13.6 + 2019-003 or 10.14.5.

Since it's a NVRAM setting, you do it once, all your macOS installs that have the mitigation (10.12.6 + 2019-003, or 10.13.6 + 2019-003 or 10.14.5) will respect that.

 

[Squuiid]

Disabling Hyper-Threading works perfectly with 10.13.6 + Security Update 2019-003:

This is from Recovery, grabbed manually via screencapture command:

Now, after Hyper-Threading disabling and shutdown:

system_profiler SPHardwareDataType; sysctl machdep.cpu.brand_string; sysctl hw.physicalcpu hw.logicalcpu

[doublepost=1558058591][/doublepost]Edit: I don't know if 144.0.0.0.0 makes any difference to disabling SMT, but I'm on 144.0.0.0.0.

Curious as to what you’re personally sticking with @tsialex.
Are you keeping HT off on your everyday machine?
I’m in two minds about it.

 

[tsialex]

Curious as to what you’re personally sticking with @tsialex.
Are you keeping HT off on your everyday machine?
I’m in two minds about it.

While it’s just a theoretical attack without any worm using it, I’m going to keep disabled with my Mac that I use most of the time to use the internet, but I’m keeping HT enabled with my Mac that I use to compile/encode.

I think that are a lot of easier ways to hack people than MDS data exfiltration. For enterprise and governments, it’s best practice to just disable HT and we will see that this may be the rule from now on.

For common, non targeted people, best internet behaviour and best security practices will always be more effective than keeping HT disabled.

 

[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

 

[MisterAndrew]

There's a tool you can run on your system to check the vulnerability status that's available to download from https://mdsattacks.com. Does anyone know how to interpret the results?

This is what I got (this is with Hyper-Threading (SMT) disabled).

System:

* Operating System: Darwin 18.6.0

* Processor: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz

* Microarchitecture: Westmere

* Microcode: 0x7a48470000001f

* Memory: 48.00 GiB


Direct Branch Speculation:

* Status: Vulnerable

* __user pointer sanitization: Disabled


Indirect Branch Speculation:

* Status: Vulnerable

* Retpoline: Disabled

* IBPB: Disabled

* IBRS: Disabled

* STIBP: Disabled

* SMEP: Not Available


Speculative Store Bypass:

* Status: Vulnerable

* Speculative Store Bypass Disable: OS Support


Meltdown:

* Status: Vulnerable

* KPTI Present: Yes

* KPTI Enabled: Yes

* PCID Accelerated: Yes

* PCID Invalidation: No


L1 Terminal Fault:

* Status: Vulnerable

* L1TF Present: No

* PTE Inversion: No

* SMT: Unaffected

* L1d Flush Present: No

* L1d Flush: Available


Micro-architectural Data Sampling:

* Line Fill Buffers (MFBDS): Vulnerable

* Store Buffers (MSBDS): Vulnerable

* Load Ports (MLPDS): Vulnerable

* Uncached Memory (MDSUM): Vulnerable

* SMT: Unaffected

* MD_CLEAR: Not Available

 

[Aiwi]

For reference, here's a MacBook Pro 15" 2017 on Mojave 10.14.5.
HT is on. Boot ROM Version: 194.0.0.0.0


System:
* Operating System: Darwin 18.6.0
* Processor: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
* Microarchitecture: Kaby Lake
* Microcode: 0xb4
* Memory: 16.00 GiB

Direct Branch Speculation:
* Status: Vulnerable
* __user pointer sanitization: Disabled

Indirect Branch Speculation:
* Status: Vulnerable
* Retpoline: Disabled
* IBPB: Disabled
* IBRS: Disabled
* STIBP: Disabled
* SMEP: Enabled

Speculative Store Bypass:
* Status: Vulnerable
* Speculative Store Bypass Disable: OS Support

Meltdown:
* Status: Vulnerable
* KPTI Present: Yes
* KPTI Enabled: Yes
* PCID Accelerated: Yes
* PCID Invalidation: Yes

L1 Terminal Fault:
* Status: Vulnerable
* L1TF Present: No
* PTE Inversion: No
* SMT: Vulnerable
* L1d Flush Present: No
* L1d Flush: Available

Micro-architectural Data Sampling:
* Line Fill Buffers (MFBDS): Vulnerable
* Store Buffers (MSBDS): Vulnerable
* Load Ports (MLPDS): Vulnerable
* Uncached Memory (MDSUM): Vulnerable
* SMT: Vulnerable
* MD_CLEAR: Available

 

[startergo]

Zbook15 g4

 

[bsbeamer]

In case it's helpful for anyone to know - MacBookPro11,3 with i7-4960HQ is showing:

signature: 0x40661
microcode_version: 0x1b
processor_flag: 0x5

It appears the Intel microcode list has been at least partially applied for updates marked as "production" when updated via the standard macOS updates, on at least some older machines. This specific processor is listed on Page 8 and is marked as planned. This MBP11,3 is a late 2013 model.

 

[Candide1759]

Hi guys,

Just want to throw this in the mix. The Apple note says "use the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology".

So the nvram settings are independent.

First, there is a way to temporarily disable Hyper-Threading using XCode, if you want to test how your system feels with it turned off.
Instructions here:
https://apple.stackexchange.com/questions/196027/how-to-disable-hyperthreading-on-mac-os-x-yosemite

Since disabling Hyper-threading seemed tolerable to me, I applied both nvram settings after updating to Mojave.

nvram boot-args="cwae=2" # "enable additional CPU instruction" - this one seems to cause a brutal slowdown.
nvram SMTDisable=%01 # this disables Hyperthreading.

Ridiculously sluggish.

So I reset NVRAM and just applied the SMTDisable=%01. Acceptable for general use.

I ran the mdstool-cli and attached the results for those of you who want to investigate what the difference is with and without the "additional CPU instruction" setting.

System:

* Operating System: Darwin 18.6.0
* Processor: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
* Microarchitecture: Broadwell
* Microcode: 0x2d
* Memory: 16.00 GiB

Direct Branch Speculation:
* Status: Vulnerable
* __user pointer sanitization: Disabled

Indirect Branch Speculation:
* Status: Vulnerable
* Retpoline: Disabled
* IBPB: Disabled
* IBRS: Disabled
* STIBP: Disabled
* SMEP: Enabled

Speculative Store Bypass:
* Status: Vulnerable
* Speculative Store Bypass Disable: OS Support

Meltdown:
* Status: Not Affected
* KPTI Present: Yes
* KPTI Enabled: No
* PCID Accelerated: Yes
* PCID Invalidation: Yes

L1 Terminal Fault:
* Status: Not Affected
* L1TF Present: No
* PTE Inversion: No
* SMT: Unaffected
* L1d Flush Present: No
* L1d Flush: Available

Micro-architectural Data Sampling:
* Line Fill Buffers (MFBDS): Not Affected
* Store Buffers (MSBDS): Not Affected
* Load Ports (MLPDS): Not Affected
* Uncached Memory (MDSUM): Not Affected
* SMT: Unaffected
* MD_CLEAR: Not Required

 

[Robert71B]

Hi guys,

Just want to throw this in the mix. The Apple note says "use the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology".

So the nvram settings are independent.

First, there is a way to temporarily disable Hyper-Threading using XCode, if you want to test how your system feels with it turned off.
Instructions here:
https://apple.stackexchange.com/questions/196027/how-to-disable-hyperthreading-on-mac-os-x-yosemite

Since disabling Hyper-threading seemed tolerable to me, I applied both nvram settings after updating to Mojave.

nvram boot-args="cwae=2" # "enable additional CPU instruction" - this one seems to cause a brutal slowdown.
nvram SMTDisable=%01 # this disables Hyperthreading.

Ridiculously sluggish.

So I reset NVRAM and just applied the SMTDisable=%01. Acceptable for general use.

I ran the mdstool-cli and attached the results for those of you who want to investigate what the difference is with and without the "additional CPU instruction" setting.

System:

* Operating System: Darwin 18.6.0
* Processor: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
* Microarchitecture: Broadwell
* Microcode: 0x2d
* Memory: 16.00 GiB

Direct Branch Speculation:
* Status: Vulnerable
* __user pointer sanitization: Disabled

Indirect Branch Speculation:
* Status: Vulnerable
* Retpoline: Disabled
* IBPB: Disabled
* IBRS: Disabled
* STIBP: Disabled
* SMEP: Enabled

Speculative Store Bypass:
* Status: Vulnerable
* Speculative Store Bypass Disable: OS Support

Meltdown:
* Status: Not Affected
* KPTI Present: Yes
* KPTI Enabled: No
* PCID Accelerated: Yes
* PCID Invalidation: Yes

L1 Terminal Fault:
* Status: Not Affected
* L1TF Present: No
* PTE Inversion: No
* SMT: Unaffected
* L1d Flush Present: No
* L1d Flush: Available

Micro-architectural Data Sampling:
* Line Fill Buffers (MFBDS): Not Affected
* Store Buffers (MSBDS): Not Affected
* Load Ports (MLPDS): Not Affected
* Uncached Memory (MDSUM): Not Affected
* SMT: Unaffected
* MD_CLEAR: Not Required

View attachment 839076

Interesting that they are independent “fixes”; i’ve Long been looking for a way to permanently switch off HT so my cores are faster on single-threaded tasks...

Thank you for the explanation that cwae=2 means to add an additional cpu instruction. And especially for isolating this as the slowdown factor in this fix!
Could somebody explain in more detail what that means?
I.e. does it add some undisclosed additional instruction set with a secret code number “2”
Or maybe it just makes the cpu generally handle one more instruction set (like one step further from RISC?)

Many thanks for your thoughtful answers!

Robert

 

[Robert71B]

Can anybody confirm that running both fixes will protect a 5,1 from the vulnerability?
Or is it then just less unprotected than a current / recent Mac?

 

[bookemdano]

Hi guys,

Just want to throw this in the mix. The Apple note says "use the Terminal app to enable an additional CPU instruction and disable hyper-threading processing technology".

So the nvram settings are independent.

First, there is a way to temporarily disable Hyper-Threading using XCode, if you want to test how your system feels with it turned off.
Instructions here:
https://apple.stackexchange.com/questions/196027/how-to-disable-hyperthreading-on-mac-os-x-yosemite

Since disabling Hyper-threading seemed tolerable to me, I applied both nvram settings after updating to Mojave.

nvram boot-args="cwae=2" # "enable additional CPU instruction" - this one seems to cause a brutal slowdown.
nvram SMTDisable=%01 # this disables Hyperthreading.

Ridiculously sluggish.

So I reset NVRAM and just applied the SMTDisable=%01. Acceptable for general use.

I ran the mdstool-cli and attached the results for those of you who want to investigate what the difference is with and without the "additional CPU instruction" setting.

System:

* Operating System: Darwin 18.6.0
* Processor: Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
* Microarchitecture: Broadwell
* Microcode: 0x2d
* Memory: 16.00 GiB

Direct Branch Speculation:
* Status: Vulnerable
* __user pointer sanitization: Disabled

Indirect Branch Speculation:
* Status: Vulnerable
* Retpoline: Disabled
* IBPB: Disabled
* IBRS: Disabled
* STIBP: Disabled
* SMEP: Enabled

Speculative Store Bypass:
* Status: Vulnerable
* Speculative Store Bypass Disable: OS Support

Meltdown:
* Status: Not Affected
* KPTI Present: Yes
* KPTI Enabled: No
* PCID Accelerated: Yes
* PCID Invalidation: Yes

L1 Terminal Fault:
* Status: Not Affected
* L1TF Present: No
* PTE Inversion: No
* SMT: Unaffected
* L1d Flush Present: No
* L1d Flush: Available

Micro-architectural Data Sampling:
* Line Fill Buffers (MFBDS): Not Affected
* Store Buffers (MSBDS): Not Affected
* Load Ports (MLPDS): Not Affected
* Uncached Memory (MDSUM): Not Affected
* SMT: Unaffected
* MD_CLEAR: Not Required

View attachment 839076

So it was your experience that the "additional CPU instruction" caused the sluggishness you saw?

and maybe it's my pre-coffee eyes but I see absolutely no difference in the results with/without the "additional CPU instruction"

 

[bsbeamer]

Can anybody confirm that running both fixes will protect a 5,1 from the vulnerability?
Or is it then just less unprotected than a current / recent Mac?

Still no confirmation from Apple...

 

[Candide1759]

So it was your experience that the "additional CPU instruction" caused the sluggishness you saw?

and maybe it's my pre-coffee eyes but I see absolutely no difference in the results with/without the "additional CPU instruction"

I didn't rigorously prove that was the cause by trying it more than once. Actually, I'm sure that would not be the typical experience because I don't think Apple would have released it if they thought any significant fraction of people would have experienced that level of slowdown.

I'm just going through a normal upgrade process and following tech notes, shouldn't be anything I'm doing that's out of the ordinary to cause a weird slowdown. Mainly I wanted to encourage someone else to try applying the fixes separately and report an objective benchmark.