MP 1,1-5,1 MacPro5,1: BootROM thread | 144.0.0.0.0

[bookemdano]

It's all pretty interesting then. I had assumed the new FW versioning scheme could have been simply due to fundamental changes to allow flashing without an EFI GPU installed (meaning there should be zero expectation of any other changes going forward).

But with tsialex's explanation that the ability to flash sans-EFI was actually solely implemented in the flasher itself, now I really do wonder if Apple could have further improvements in mind--especially relating to the GPU given that the only "fix" in the new FW (aside from even newer microcodes than 0089) was upping the link speed for AMD GPUs to 5 GT/s.

The inability to flash a new firmware without an EFI card was a major obstacle they were required to fix (since theoretically, someone who's been running Lion all these years could decide to jump straight up to Mojave and would be absolutely screwed without the FW update since their cMP would not be able to boot from the newly-converted APFS drive.

So if that was their only goal, they could have simply fixed the flasher, added the new microcodes to the existing MP51 firmware and released it as MP51.0091.B00.

And yet they chose to completely change the FW versioning for this release, with a GPU-related improvement that affects their recommended AMD GPUs. Hmmmm....

There is still absolutely no guarantee that any additional improvements will be implemented, but the fact that the EFI flashing requirement fix was totally unrelated to the new FW file itself gives me some optimism that Apple isn't just half-assing this upgrade for the cMP.

 

[h9826790]

It's all pretty interesting then. I had assumed the new FW versioning scheme could have been simply due to fundamental changes to allow flashing without an EFI GPU installed (meaning there should be zero expectation of any other changes going forward).

But with tsialex's explanation that the ability to flash sans-EFI was actually solely implemented in the flasher itself, now I really do wonder if Apple could have further improvements in mind--especially relating to the GPU given that the only "fix" in the new FW (aside from even newer microcodes than 0089) was upping the link speed for AMD GPUs to 5 GT/s.

The inability to flash a new firmware without an EFI card was a major obstacle they were required to fix (since theoretically, someone who's been running Lion all these years could decide to jump straight up to Mojave and would be absolutely screwed without the FW update since their cMP would not be able to boot from the newly-converted APFS drive.

So if that was their only goal, they could have simply fixed the flasher, added the new microcodes to the existing MP51 firmware and released it as MP51.0091.B00.

And yet they chose to completely change the FW versioning for this release, with a GPU-related improvement that affects their recommended AMD GPUs. Hmmmm....

There is still absolutely no guarantee that any additional improvements will be implemented, but the fact that the EFI flashing requirement fix was totally unrelated to the new FW file itself gives me some optimism that Apple isn't just half-assing this upgrade for the cMP.

May be they finally decided to build the 7,1 base on the 5,1. Therefore, suddenly need to make the 5,1 firmware “up to date” but not just fixing the old issue.

 

[tsialex]

It's all pretty interesting then. I had assumed the new FW versioning scheme could have been simply due to fundamental changes to allow flashing without an EFI GPU installed (meaning there should be zero expectation of any other changes going forward).

But with tsialex's explanation that the ability to flash sans-EFI was actually solely implemented in the flasher itself, now I really do wonder if Apple could have further improvements in mind--especially relating to the GPU given that the only "fix" in the new FW (aside from even newer microcodes than 0089) was upping the link speed for AMD GPUs to 5 GT/s.

The inability to flash a new firmware without an EFI card was a major obstacle they were required to fix (since theoretically, someone who's been running Lion all these years could decide to jump straight up to Mojave and would be absolutely screwed without the FW update since their cMP would not be able to boot from the newly-converted APFS drive.

So if that was their only goal, they could have simply fixed the flasher, added the new microcodes to the existing MP51 firmware and released it as MP51.0091.B00.

And yet they chose to completely change the FW versioning for this release, with a GPU-related improvement that affects their recommended AMD GPUs. Hmmmm....

There is still absolutely no guarantee that any additional improvements will be implemented, but the fact that the EFI flashing requirement fix was totally unrelated to the new FW file itself gives me some optimism that Apple isn't just half-assing this upgrade for the cMP.

A lot of security people that published papers on Apple security, specifically on firmware security, are now working for Apple. Apple literally got every one.

Some of the criticism of Apple relates to the inconsistent firmware updates, Macs going years without BootROM fixes, microcodes and etc. We all know this by heart. Seems that Apple is changing this. I'm not gonna read anything on this, I don't expect a full revamp, but any improvement will be welcomed, even if with that improvement a long the road we gonna loose something like the capacity of injecting drivers.

 

[Spacedust]

Is Spectre Variant 3a and 4 finally fixed? 89 didn't fix these,

 

[tsialex]

Is Spectre Variant 3a and 4 finally fixed? 89 didn't fix these,

It's updated with the current microcodes that Intel made public in June. So we are current on microcodes.

But everyday Intel has a new security debacle, L1 Terminal Fault (L1TF) dropped today, I cannot say that everything is patched.
[doublepost=1534362224][/doublepost]

May be they finally decided to build the 7,1 base on the 5,1. Therefore, suddenly need to make the 5,1 firmware “up to date” but not just fixing the old issue.

I'm reading this differently, maybe Apple devs are using Mac Pros to implement/test new things. I know that something is being done now.

 

[thomasthegps]

It's updated with the current microcodes that Intel made public in June. So we are current on microcodes.

But everyday Intel has a new security debacle, L1 Terminal Fault (L1TF) dropped today, I cannot say that everything is patched.
[doublepost=1534362224][/doublepost]
I'm reading this differently, maybe Apple devs are using Mac Pros to implement/test new things. I know that something is being done now.

Is patching for these issues really necessary?

 

[tsialex]

Is patching for these issues really necessary?

After something was published, bad actors will try to exploit it. You could be certain of that, maybe not today but sometime in the future some worm/etc will spread like fire, they did that in the past and will happen again in the future.

 

[thomasthegps]

After something was published, bad actors will try to exploit it. You could be certain of that, maybe not today but sometime in the future some worm/etc will spread like fire, they did that in the past and will happen again in the future.

I meant in which situation can someome use these exploits ? Can you use these hacks from a distance or do you have to be actually sitting in front of the computer?

 

[tsialex]

I meant in which situation can someome use these exploits ? Can you use these hacks from a distance or do you have to be actually sitting in front of the computer?

It was demonstrated that by visiting web pages, the web pages could extract your credentials/passwords/etc from the RAM on unpatched systems. So imagine some bad actor buys ads from some ad network and inject the code to extract credentials. Millions of people will be vulnerable. This could happen any day.

 

[thomasthegps]

It was demonstrated that by visiting web pages, the web pages could extract your credentials/passwords/etc from the RAM on unpatched systems. So imagine some bad actor buys ads from some ad network and inject the code to extract credentials. Millions of people will be vulnerable. This could happen any day.

I was unaware of that. It does seem that patching these vulnerabilities is important lol.

 

[bookemdano]

Yeah but if they are taking the time & resources to revamp the firmware anyway, why not fix what would surely be a support nightmare once Mojave is released.

We here are enthusiasts and have been swapping video cards, etc. for a long time now. We're aware of what EFI is and why it matters.

But with Mojave, Apple is recommending the Mojave upgrade to 2010 & 2012 Mac Pro users, many of whom are not "computer people" and who use their cMP for real work. How is Apple going to explain to them that once they replace the GPU and install Mojave that they won't be able to get back to macOS from Boot camp? Is Apple going to block Mojave installs on cMPs with a boot camp partition? Or will Mojave itself disable Boot Camp Assistant from running on the cMP? I simply can't see Apple recommending users perform a PRAM reset each and every time they need to go back from Windows to macOS.

I dunno, but regardless of what happens, this has been the most interesting year for the cMP in a long, long time. And to think I almost sold mine off this Spring! Good thing I was lazy

 

[crjackson2134]

Yeah but if they are taking the time & resources to revamp the firmware anyway, why not fix what would surely be a support nightmare once Mojave is released.

We here are enthusiasts and have been swapping video cards, etc. for a long time now. We're aware of what EFI is and why it matters.

But with Mojave, Apple is recommending the Mojave upgrade to 2010 & 2012 Mac Pro users, many of whom are not "computer people" and who use their cMP for real work. How is Apple going to explain to them that once they replace the GPU and install Mojave that they won't be able to get back to macOS from Boot camp? Is Apple going to block Mojave installs on cMPs with a boot camp partition? Or will Mojave itself disable Boot Camp Assistant from running on the cMP? I simply can't see Apple recommending users perform a PRAM reset each and every time they need to go back from Windows to macOS.

I dunno, but regardless of what happens, this has been the most interesting year for the cMP in a long, long time. And to think I almost sold mine off this Spring! Good thing I was lazy

I hope they come up with something soon. I was doing fine with my MVC Flashed HD 7970 until about a hour ago when my video card stopped sending a video signal out (tried all ports). Glad I kept my old HD5870 around, but I don't see any thing about metal support in the profiler. It also twisted my Win10 bootcamp drive. It won't even let me expand the downloaded zip file that's supposed to have the correct driver. It extracts fine on the Mac side.

I've had better days for sure...

 

[handheldgames]

Yeah but if they are taking the time & resources to revamp the firmware anyway, why not fix what would surely be a support nightmare once Mojave is released.

We here are enthusiasts and have been swapping video cards, etc. for a long time now. We're aware of what EFI is and why it matters.

But with Mojave, Apple is recommending the Mojave upgrade to 2010 & 2012 Mac Pro users, many of whom are not "computer people" and who use their cMP for real work. How is Apple going to explain to them that once they replace the GPU and install Mojave that they won't be able to get back to macOS from Boot camp? Is Apple going to block Mojave installs on cMPs with a boot camp partition? Or will Mojave itself disable Boot Camp Assistant from running on the cMP? I simply can't see Apple recommending users perform a PRAM reset each and every time they need to go back from Windows to macOS.

I dunno, but regardless of what happens, this has been the most interesting year for the cMP in a long, long time. And to think I almost sold mine off this Spring! Good thing I was lazy

The easiest way to address unfixed features would be adding an * after the 2010 Mac Pro in the supported hardware list.

* listing all the features that are no longer supported.

 

[Spacedust]

It seems they've patched Spectre Variant 3a and 4:

Spectre and Meltdown mitigation detection tool v0.39+

Checking for vulnerabilities on current system
Kernel is Linux 2.6.32-754.el6.x86_64 #1 SMP Tue Jun 19 21:26:04 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU X5675 @ 3.07GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES (Intel STIBP feature bit)
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: YES (Intel SSBD)
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
* CPU microcode is known to cause stability problems: NO (model 0x2c family 0x6 stepping 0x2 ucode 0x1f cpuid 0x206c2)
* CPU microcode is the latest known available version: YES (you have version 0x1f and latest known version is 0x1f)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: Load fences)
* Kernel has array_index_mask_nospec: NO
* Kernel has the Red Hat/Ubuntu patch: YES
* Kernel has mask_nospec64 (arm64): NO
> STATUS: NOT VULNERABLE (Mitigation: Load fences)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: NO
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
* Retpoline is enabled: YES
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports PCID, performance impact of PTI will be reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl)
* Kernel supports speculation store bypass: YES (spec_store_bypass)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl)

CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
> STATUS: VULNERABLE (your CPU is known to be vulnerable, and your kernel doesn't report that it mitigates the issue, but more thorough mitigation checking by this script is being worked on (check often for new versions!))

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

 

[bookemdano]

The easiest way to address unfixed features would be adding an * after the 2010 Mac Pro in the supported hardware list.

* listing all the features that are no longer supported.

You're right, they could do that. I just hope they don't. And if the rumors are true that they still use these machines internally then maybe they've got extra incentive to get them fully functional. Not that I'd expect Apple employees to be using boot camp, but I would hope and expect that Apple requires FV2 on all their machines.

 

[Spacedust]

Another amazing find! This new firmware fixes a bug causing all MVC flashed cards from Maxwell and Pascal series to stay on PCIe 1.1 when resuming from standby under Windows. It only worked on clean boot before, now I've resumed from standby on my Windows 7 and it remained on PCIe 2.0
[doublepost=1534369707][/doublepost]If they only do a fix to the SMC as well to fix these noisy PCI and PS fans that would be great or maybe it's already fixed? ;-)

 

[weckart]

I think this one is in the bag people...

I admire your optimism but I don’t see much justification for it. In order to enable boot screens, Apple would either have to doctor the cMP bootrom to support these particular third party cards only or would itself have to provide a firmware update for those cards and deal with any support issues arising. Neither sounds like a remote possibility.

The most likely scenario is that Apple has some understanding from AMD that a firmware update to support the cMP is in train for those two RX5x0 cards. Counting against that is the credibility of any business sinking resources into a product modification for no possible reward. Why would AMD sell Mac cards at PC prices?

 

[goMac]

I admire your optimism but I don’t see much justification for it. In order to enable boot screens, Apple would either have to doctor the cMP bootrom to support these particular third party cards only or would itself have to provide a firmware update for those cards and deal with any support issues arising. Neither sounds like a remote possibility.

Adding a GOP EFI driver to get boot screens seems like a completely reasonable thing they could do. No "doctoring" required, or having to worry about "particular cards."

 

[crjackson2134]

Well, my trusty MVC flashed HD 7970 died today at the worst possible time. I use boot picker heavily as it works better than the startup disk applet on my system. In fact, that rarely works for me at all anymore. It's like I just selected reboot for the same drive.

I would like for someone here that has a Sapphire Pulse RX580 to test something for me so I can decide if that card will suit my needs.

Since there is no boot picker screen, I would like for someone to boot up holding down the CMD+R keys and boot into recovery mode. You should get screen output when it loads since it's working with base.dmg that holds all the drivers.
From there, please go to the top toolbar and click the apple icon and select the startup drive option.

If this works well, I don't need a boot picker screen at all, and I can just use the recovery bundle for my boot picker with the RX580.

 

[goMac]

Glad I kept my old HD5870 around, but I don't see any thing about metal support in the profiler.

The 5870 does not support Metal and will not work with Mojave.

Which is certainly a strange place for Apple to be. This means that no stock 2010/2012 Mac Pro can run Mojave.

 

[crjackson2134]

The 5870 does not support Metal and will not work with Mojave.

Which is certainly a strange place for Apple to be. This means that no stock 2010/2012 Mac Pro can run Mojave.

Yeah, it actually works pretty will in Mojave. The GUI is smooth and fast so obviously you don't need metal support for just the interface. Watch video, working on documents, and browsing is not hampered at all.

You shouldn't be able to INSTALL the OS, or use metal accelerated applications properly, but the OS itself is fine.

 

[flowrider]

This means that no stock 2010/2012 Mac Pro can install Mojave.

Corrected for accuracy - We all know this to be the case. Apple told us so:

Lou

 

[crjackson2134]

Besides, I have an I have a Sapphire Pulse RX 580 on the way.

I’m gonna miss Boot Picker but I’ve already figured out how to cope with it using Apple’s own solutions. Perhaps it’s there intention on how we will work around this.

Unless I’m mistaken, all you have to do is boot into recovery mode and change startup disk. It’s graphical, it’s easy, it works

 

[handheldgames]

Besides, I have an I have a Sapphire Pulse RX 580 on the way.

I’m gonna miss Boot Picker but I’ve already figured out how to cope with it using Apple’s own solutions. Perhaps it’s there intention on how we will work around this.

Unless I’m mistaken, all you have to do is boot into recovery mode and change startup disk. It’s graphical, it’s easy, it works

Did the highpoint ssd7101-a starve the 7970 of air for cooling. The 7970 was known to run a bit warmer than the 7950.

 

[crjackson2134]

Did the highpoint ssd7101-a starve the 7970 of air for cooling. The 7970 was known to run a bit warmer than the 7950.

No, the card is much longer than the 7101A and the fan was mostly exposed to free space. The card also ran on reduced voltage and never ran hot that I’m aware of.

It just gave up the ghost on a reboot surge I think.

I am a little concerned about the new card next to the 7101A however. It will definitely block the rear fan space.

How can I test for heat issue with that card once installed.