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

Discussion in 'Mac Pro' started by MisterAndrew, May 15, 2019.

Thread Status:
The first post in this thread is a WikiPost, and can be edited by anyone with the appropriate permissions.
  1. MisterAndrew, May 15, 2019
    Last edited by MisterAndrew: May 27, 2019

    MisterAndrew macrumors 65816

    MisterAndrew

    Joined:
    Sep 15, 2015
    Location:
    Portland, Oregon
    #1
    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)
     
  2. tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #2
    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:
    16770D18-6BCD-4D33-B87C-497E67C02D94.jpeg
     
  3. MisterAndrew thread starter macrumors 65816

    MisterAndrew

    Joined:
    Sep 15, 2015
    Location:
    Portland, Oregon
    #3
    To be clear, for myself and others, these Macs are not vulnerable after disabling Hyper-Threading Technology?
     
  4. tsialex, May 15, 2019
    Last edited: May 15, 2019

    tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #4
    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.
     
  5. tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #5
  6. bookemdano macrumors 65816

    Joined:
    Jul 29, 2011
    #6
    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.
     
  7. tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #7
    late-2010 Mac Pro?!?

    Screen Shot 2019-05-15 at 17.39.05.png
     
  8. bookemdano macrumors 65816

    Joined:
    Jul 29, 2011
    #8
    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.
     
  9. tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #9
    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.
     
  10. Lycestra macrumors newbie

    Joined:
    Oct 1, 2018
    Location:
    Cheesey Midwest
    #10
    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!)
     
  11. bookemdano macrumors 65816

    Joined:
    Jul 29, 2011
    #11
    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.
     
  12. tsialex, May 16, 2019
    Last edited: May 17, 2019

    tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #12
    Disabling Hyper-Threading works perfectly with 10.13.6 + Security Update 2019-003:

    This is from Recovery, grabbed manually via screencapture command:

    SMTDisable.Recovery.png

    Now, after Hyper-Threading disabling and shutdown:

    Code:
    system_profiler SPHardwareDataType; sysctl machdep.cpu.brand_string; sysctl hw.physicalcpu hw.logicalcpu
    
    [​IMG]


    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.
     
  13. Squuiid macrumors 65816

    Squuiid

    Joined:
    Oct 31, 2006
    #13
    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.
     
  14. tsialex, May 17, 2019
    Last edited: May 17, 2019

    tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #14
    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.
     
  15. tsialex, May 17, 2019
    Last edited: May 17, 2019

    tsialex macrumors 601

    tsialex

    Joined:
    Jun 13, 2016
    Location:
    Brazil
    #15
    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:

    SMTDisable.Terminal.png

    So, you can only disable Hyper-Threading with BootROM 144.0.0.0.0
     
  16. MisterAndrew, May 20, 2019
    Last edited: May 20, 2019

    MisterAndrew thread starter macrumors 65816

    MisterAndrew

    Joined:
    Sep 15, 2015
    Location:
    Portland, Oregon
    #16
    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
     
  17. Aiwi macrumors newbie

    Aiwi

    Joined:
    Oct 21, 2010
    #17
    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
     
  18. bsbeamer macrumors 68020

    Joined:
    Sep 19, 2012
    #19
    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.
     
  19. Candide1759 macrumors newbie

    Candide1759

    Joined:
    May 26, 2019
    #20
    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

    MBP HT Disabled mdstool.png
     
  20. Robert71B macrumors newbie

    Robert71B

    Joined:
    Nov 8, 2017
    #21

    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
     
  21. Robert71B macrumors newbie

    Robert71B

    Joined:
    Nov 8, 2017
    #22
    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?
     
  22. bookemdano macrumors 65816

    Joined:
    Jul 29, 2011
    #23
    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"
     
  23. bsbeamer macrumors 68020

    Joined:
    Sep 19, 2012
    #24
    Still no confirmation from Apple...
     
  24. Candide1759 macrumors newbie

    Candide1759

    Joined:
    May 26, 2019
    #25
    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.
     
Thread Status:
The first post in this thread is a WikiPost, and can be edited by anyone with the appropriate permissions.

Share This Page

42 May 15, 2019