Yes, so long as Windows is booted through OpenCore.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 1,1-5,1 Manually Configured OpenCore on the Mac Pro
- Thread starter cdf
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
And by "booted through" you mean a system that initializes at boot up from the blessed EFI partition containing OC.
So working my way through the manual with your excellent insights, I see that "ProtectSecureBoot" description states is "protects" UEFI secure boot variables from being written. In this case, Windows security certificate would be a "variable" write that would be denied, perhaps causing the dreaded NVRAM fragmentation referred to in the manual. Does this stay in effect even after Windows is full booted and operational? Are there things the Windows Update process could do (like the major update this autumn) to inject something into the NVRAM despite the OS settings? Or is it a sticky setting that protect the NVRAM regardless of what any OS intends to do?
And your earlier recommendation of setting "BootProtect" to bootstrap: I noticed in the default config.plist, BootProtect is set to None while "RequestBootVarRouting" is enabled as needed for the Bootstrap setting. Why wouldn't ProtectSecureBoot just be set to BootStrap by default? Is there any risk or limitations to having the default setting as Bootstrap for ProtectSecureBoot on a Mac Pro?
Last edited:
No, it’s not. Unless you have MP51.0087.B00 as your current BootROM, SecureBoot won't brick a firmware.
For example: MemoryConfig, a very big variable that stores the DIMM SPD and the fine tuning parameters for the DIMM, is usually worse than SecureBoot, since you have one for each DIMM and it's very common to see BootROM dumps with 3x the quantity of the DIMMs the Mac Pro have installed.
People are focusing soo much on SecureBoot and are not seeing the real underlying problem.
I'll repost here what I wrote yesterday on other thread:
While it's easy to confirm if your Mac Pro firmware have SecureBoot certificates inside the NVRAM volume, just run binwalk with your BootROM image dump and see if the output show any X.509 certificates inside, SecureBoot is just a red-herring.
The real problem is the NVRAM data/variables not being erased anymore and the NVRAM volume part of the BootROM accumulating superseded variables over the years to the point that it's full and then it self destructs. SecureBoot just makes this process much faster since the certificates/DBs/PKs occupy so much valuable space inside the NVRAM volume. MP5,1 NVRAM size is tiny for todays standards, it's 1/4 of the size of a 2019 iMac, for example.
The fragmentation process that self destroy the NVRAM volume and bricks a Mac Pro was first observed back in 2018 when I started to investigate dumps extracted from bricked Mac Pros. At the beginning, it was very poorly understood and we (me and @h9826790) thought that what was causing the bricks was just SecureBoot + the crash caused by the missing microcodes of MP51.0087.B00. Some time later, I started to notice that bricks were happening even with Mac Pros that never had MP51.0087.B00 nor Windows installed. Took lot's of different Mac Pro dumps and months to track and understood what was really going on.
Firmware fragmentation is not easy to check, to see it you have to know what is being written repeatedly, and most importantly, where is being written on the NVRAM volume, this varies from Mac to Mac, there is no one tool to check this and it's not just one parameter that you track to know that is a problem. It's several things at once, for example I have to investigate parameters like free space/quantity of MemoryConfig/bluetoothActiveController per store, checksums/free space indicators to see if a NVRAM volume is healthy or not.
My point is, an almost brick is easy to identify since the NVRAM is almost without free space, but to know that a store is becoming corrupt is more art than science. It's not just one thing, but the combination of several parameters that you infer based on the hardware config, sometimes, an almost brick with a single CPU tray would be a just above than normal dual CPU tray with 8 DIMMs NVRAM volume.
Last edited:
¡Ay, caramba! This is definitely over my pay grade! Lol
So am I back to square one? Is there no way to ensure Windows WON'T trash the firmware even under an OC boot?
LOL, I just wrote that Windows UEFI has nothing to do with the real problem that causes the bricks, SecureBoot just accelerates it.
Please read again what I wrote.
LOL! I read it multiple times already...Still don't get it. But not sure I have to for what I'm trying to understand. As a layman I've read many warnings, most were from discussions involving you, against allowing the firmware to be corrupted by a Windows EFI installation. I would like to say I understood the brunt of those discussions but really most of it has simply chaffed my scalp. LolLOL, I just wrote that Windows has nothing to do with the real problem that causes the bricks, SecureBoot just accelerates it.
Please read again what I wrote.
As a simpleton that has used dosdue1 patchers, I'm now contemplating upgrading to BS to which there is no more dosdued1. ( ‘Alas, poor Yorick! I knew him well’). It seems to me OC is my best option as noted with my successful upgrade to BS yesterday on a 2012 Mac Pro. Unfortunately legacy Window installs that I have relied on appear to not work under OC. I couldn't even get the Windows install DVD to boot up.
So I went to the OC manual which states it does not officially support Windows installations but that Boot Camp assistant installations, if adhered to, should work. However, the appendix in post 1 provides an installation guide that does not use Boot Camp to install Windows as the OC manual suggests, without any clarification as to why the different process is needed. Ultimately I just want to know how to ensure my firmware is protected from corruption.
I was beginning to feel comfortable with the discussion regarding the ProtectSecureBoot and BootProtect settings but wasn't sure from what you wrote that you weren't contradicting the discussion.
Thanks for your feedback.
So for the benefit of this thread is Windows in UEFI able to corrupt the firmware if the certificates are blocked? I see the NVRAM can be corrupted many different ways, but is Windows one of the ways (assume it is blocked from writing the certificate)?LOL, I just wrote that Windows UEFI has nothing to do with the real problem that causes the bricks, SecureBoot just accelerates it.
Please read again what I wrote.
Hello all. I have no programing experience and I’m trying to complete Part II - Advanced Configuration, but I’m having trouble verifying the config.plist.
Machine is MacPro 5,1 w/GeForce GTX 760. Latest Catalina on NVME. No apparent issues so far.
I’ve tried editing config.plist via TextEdit and I what I paste from the page 1 guide doesn’t match the formatting of the plist file (too far left). I’ve also tried the ProperTree method but both end up with Terminal saying that config.plist doesn’t exit, isn’t readable, or is not a regular file.
Does this sound like a problem with how I’ve pasted the XML values from page one?
Any suggestions for a GUI hand-holding editor?
Netflix is working so DRM is functional- so therefore hardware acceleration is already enabled? Yet the actual path to my GPU isn’t there, just the generic form.
Should I leave well enough alone? Or should the guide be followed to the letter?
Machine is MacPro 5,1 w/GeForce GTX 760. Latest Catalina on NVME. No apparent issues so far.
I’ve tried editing config.plist via TextEdit and I what I paste from the page 1 guide doesn’t match the formatting of the plist file (too far left). I’ve also tried the ProperTree method but both end up with Terminal saying that config.plist doesn’t exit, isn’t readable, or is not a regular file.
Does this sound like a problem with how I’ve pasted the XML values from page one?
Any suggestions for a GUI hand-holding editor?
Netflix is working so DRM is functional- so therefore hardware acceleration is already enabled? Yet the actual path to my GPU isn’t there, just the generic form.
Should I leave well enough alone? Or should the guide be followed to the letter?
UEFI Windows only bricks a BootROM if it crashes while signing the BootROM. This only happens if you don't have microcodes inside the BootROM, i.e. the mistake Apple did back with MP51.0087.B00.
UEFI Windows accelerates the underlying fragmentation problem because it uses a lot of space inside the tiny MP5,1 NVRAM, but it's not the responsible for the bricking at all - except with the perfect storm MP51.0087.B00 that probably almost no one have it now.
UEFI Windows is not responsible for the bricking of Mac Pros, the NVRAM volume fragmentation/FS corruption is. UEFI Windows don't cause the fragmentation/corruption, it's already happening inside each MP5,1 BootROM after almost 12 years for early-2009 Mac Pros, almost 11 years for mid-2010, almost 9 years for mid-2012. OC protecting it or not - it's happening, even if you protect it in any way imaginable, when you change a DIMM, bless a disk, or iCloud adds a Wi-Fi credential and etc, it's happening.
When Apple designed the MP5,1 NVRAM, they never envisioned that it would be a working/relevant Mac for so many people today or that the NVRAM volume would be so important and utilised as it is nowadays. The filesystem is basically flawed for long term usage and the space available is ridiculous for today's standards.
Last edited:
Great. Thanks. So to clarify for the users once Windows is prevented from writing to the NVRAM in respect to installing and using Windows through OC there is nothing to worry about, i.e more or less in this perspective it behaves like the CSM Windows (Bootcamp Windows).
Windows SecureBoot is not the problem in itself. Eliminating it via OC or not using UEFI Windows, the bricking process continues as always, maybe at slower pace.
People that never used Windows or installed MP51.0087.B00 bricked the Mac Pro.
From what I learned installing OC: you shouldn't edit config.plist from the EFI partition, it will have issues saving the file. Copy it from the EFI partition to a location like your desktop, edit it, verify it with plutil, copy it back to the EFI partition. Regarding formatting, when you run the 'plutil' command to verify the file, it will apply the proper indenting to the code you pasted in.
Regarding the path of your hardware, YES you need the actual path to your hardware if you want the device to be affected by the changes you made to config file. For the sake of stability, you do not want an incorrect hardware device being referenced.
Regarding hardware acceleration itself? I don't know what it really does (GPU?, CPU?) or what it really affects or what it benefits really are. I asked that question earlier (as have others from my searching) but there never seems to be a direct answer to that question that I've been able to find. I skipped PART 2 because I have not found any explanation as to what its really doing or why its needed. My system (knock on wood) is running fine w/o it so far.
And just as a recommendation, YES, if your going to implement the guides, follow them to the letter!
I am not talking about the bricking process, but about Windows UEFI accelerating the process. The goal here is to prevent Windows from accelerating the firmware corruption.
I've written that the real problem was not understood when the initial bricks started to happen. Now it's a known problem, happens with PCs too, and a solution was found to overcome the problem, to flash a reconstructed never booted image from time to time. It's a shittty solution, I'm the first one to tell you that, but works.
You shouldn't look at BigSur and MP5,1 right now. It's not stable at all. Let people that can solve the problems debug it and overcome the problems. Stick with Catalina.
SecureBoot is not the problem. Stop focusing on it and learn about what is really happening.
Like I wrote, SecureBoot just makes it faster since it takes so much space inside the NVRAM stores.
If you remove Windows SecureBoot from the equation, the bricking process will continue at slower pace.
HAH! Thanks! This I understand better....So is there any Great Reset one can do to refresh and begin again? Or am I being too simplistic. Reload the firmware with a virgin image, if such a thing exists. I take it a PRAM reset does not clear such variables from the NVRAM?
On my cmp 5,1 when I have my 30 inch Cinema Display plugged in to my rx 580 video card on the display port I get this at boot up and how can fix it and with a duel monitor set up only one port shows a boot screen and how can show a boot screen on all ports on my rx 580
Attachments
No, it does not exits, each Mac Pro has it's own BootROM that is unique, but it's possible to create a never booted image tailored for your Mac Pro, exactly the same as the OEM manufacturer did during the production of the backplane, but updated to the current EFI release. Lot's of people on this thread already have it.
NVRAM reset only removes public variables and when the FS is working correctly. SecureBoot, MemoryConfig and lot's of others variables are not public.
A public variable is what you can see with nvram -xp, everything else is what I'm calling non-public ones.
Thanks. I guess since this is an inevitable doom for my machine, I'll stick to Mojave and legacy BIOS Windows to slow the process. I appreciate your feedback and insights.
Boot natively into Mojave and double check your config, making sure that hybridization is properly enabled. Please note that Big Sur should only be considered experimental at this point.
Perhaps you can try setting another display mode (you can use the debug version of OpenCore to obtain the available modes). As for your dual monitor setup, I don't believe that the bootscreen can be mirrored on multiple monitors.
Please, forgive me ignorance. I've just learned about this issue. Can you provide a link to a step-by-step guide as to how such a pristine, personalized BootROM can be recreated? I take it for granted that such a guide will specify whatever items (a ROM programmer?) are necessary to re-generate the boot ROM.
Hi, i do not own a MacPro, i am just curious.
If there is a way to write in non public NVRAM areas, maybe there should be a way to erase these areas?
Sorry, but this is not an end user job.
One bit misplaced and you have a brick, it’s a job for a firmware engineer that knows about Macs.