MP 1,1-5,1 MonteRand (probably the start of an ongoing saga)

[Syncretic]

EDIT (20dec21): It appears that only 12.1b1 requires MonteRand - subsequent betas and the 12.1 released version do not seem to have the RDRAND problem addressed by MonteRand. Also, it appears that the 12.1 released (non-beta) version does not require SurPlus, either.

---

Yesterday, Monterey 12.1b1 was seeded to developers. @khronokernel observed that 12.1b1 contains a dependency on the RDRAND instruction, which effectively breaks pre-Ivy Bridge systems (that includes Mac Pro 5,1 and earlier). I am not in a position to install 12.1b1 at the moment, but I was able to create a patch blindly; see below. Thanks to @khronokernel, @educovas, and others for the quick testing.

The patches below need to be used in addition to the existing SurPlus patches. The OCLP crew already have these in hand, so I'd expect them to appear in a nightly build fairly soon (EDIT: they have). Based on what I'm hearing, it doesn't appear that the installer requires these patches, but they're necessary to actually boot the system (clarification of that point from someone who's actually installed 12.1b1 is welcome).

IMPORTANT POINTS:

• The new rdrand instructions appear in the kernel zone memory management code, apparently performing similar functions to the code that SurPlus patched. The patches below effectively disable that randomization and allow pre-Ivy Bridge systems to operate correctly. This should be functionally identical from a user's perspective, and it probably does not degrade security in a practical sense, but it's possible that system security is impaired or compromised by these patches. Until further analysis can be done, we should assume that these patches create a potential security issue, and avoid using them on sensitive or production systems. (Of course, it's unlikely that you're installing a beta on a production system anyway, but...)
• Until there are more reports of successful tests, these patches should be considered "beta" at best.
• It seems fair to assume that going forward, Apple will continue to leverage instructions from the lowest supported systems, and we'll continue to see issues like this arise as MacOS evolves. Some such foreseeable issues are easily defused, but some others I can think of could cause serious problems. Our classic Macs aren't at the end of the road quite yet, but it's probably looming in the distance. Be prepared.
• I will post a more detailed writeup of the problem and this solution when I have some time. It's possible that this will be the only change needed for 12.1, but if they release a flurry of betas like they did for 12.0, there may be a cat-and-mouse game for a while, so the writeup might have to wait until things settle down. From a high level, it's just another plot twist in the SurPlus saga, the introduction of rdrand instructions to handle the randomization of internal kernel memory; the patches below just remove the rdrand instructions and use a constant value instead.

---

Here are the patches (you'll want both), which go in the Kernel - Patch array, just like SurPlus. It doesn't matter if these appear before or after SurPlus, so long as they're all present. NOTE: if you're doing this manually, remember to also change the MaxKernel value in both of the existing SurPlus patches to 21.2.0!

            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>Base</key>
                <string>_work_interval_port_type_render_server</string>
                <key>Comment</key>
                <string>MonteRand (12.1b1) #1</string>
                <key>Count</key>
                <integer>1</integer>
                <key>Enabled</key>
                <true/>
                <key>Find</key>
                <data>
                D8fxc/sh8TnRc/WJyUiLlM3Q/f//
                </data>
                <key>Identifier</key>
                <string>kernel</string>
                <key>Limit</key>
                <integer>3900</integer>
                <key>Mask</key>
                <data>
                </data>
                <key>MaxKernel</key>
                <string>21.2.0</string>
                <key>MinKernel</key>
                <string>21.2.0</string>
                <key>Replace</key>
                <data>
                McmQkJAh8TnRc/WJyUiLlM3Q/f//
                </data>
                <key>ReplaceMask</key>
                <data>
                </data>
                <key>Skip</key>
                <integer>0</integer>
            </dict>
            <dict>
                <key>Arch</key>
                <string>x86_64</string>
                <key>Base</key>
                <string>_panic_with_thread_context</string>
                <key>Comment</key>
                <string>MonteRand (12.1b1) #2</string>
                <key>Count</key>
                <integer>1</integer>
                <key>Enabled</key>
                <true/>
                <key>Find</key>
                <data>
                D8fyc/uD4g+D+gd38w+3NEE=
                </data>
                <key>Identifier</key>
                <string>kernel</string>
                <key>Limit</key>
                <integer>10100</integer>
                <key>Mask</key>
                <data>
                </data>
                <key>MaxKernel</key>
                <string>21.2.0</string>
                <key>MinKernel</key>
                <string>21.2.0</string>
                <key>Replace</key>
                <data>
                MdKQkJCD4g+D+gd38w+3NEE=
                </data>
                <key>ReplaceMask</key>
                <data>
                </data>
                <key>Skip</key>
                <integer>0</integer>
            </dict>

Questions, comments, and discussion of this issue are welcome here.

 

[Syncretic]

Frequently Asked Questions

• Will this affect Monterey 12.0.1, Big Sur, or any earlier MacOS? Can I install this patch in a multi-boot config.plist?
  These patches contain a min/max kernel version of 21.2.0, which is 12.1b1. Even if they're present in your config.plist file, the patches won't be applied to anything other than 12.1b1, so it's safe to include them in a multi-boot environment. (Note that future betas (and 12.1 GM) may reuse the same kernel version, so we may need to make some adaptations for upcoming betas. For now, the patch is applied only to 12.1b1.)
• Why didn't you name it MonteCarlo? That's a much better name.
  It definitely is. However, I am far too sleep-deprived right now to be that clever; it was all I could do not to just name it "First Monterey 12.1b1 Patch of Probably Many to Come." Hat tip to @Ausdauersportler for being more awake than I am.
• I manually added the MonteRand patches to my config.plist, but I'm still getting boot hangs. Why?
  1) Ensure that the SurPlus patches are applied. If you're upgrading from pre-11.3, you may have missed those.
  2) Ensure that both of your SurPlus patches have a MaxKernel value of 21.2.0 (or higher). The original patches were capped at 21.1.0 for safety. (On 30oct21, I updated the repository version with 21.2.0.)
  3) If you did (1) and (2) and are still having problems, open a Terminal session, change to your OC folder, and validate your config.plist using:

  plutil -convert xml1 config.plist && plutil config.plist

  If that shows errors, fix them; if no errors are shown, post your config.plist as an attachment in this thread and ask for help. The most frequent problems with manual adds are putting them in the wrong place or missing/malforming an XML tag.

 

[socamx]

Of course, it's unlikely that you're installing a beta on a production system anyway, but...)

If only I could count the times I've brazenly moved forward on daily drivers and production systems...

Joking aside, what are the implications of newer CPU instructions being used in applications? Can an application or program call on RDRAND? If it does, what happens on a system that doesn't have this instruction? Am I right to presume the program just will fail or crash?

As always though, thank you to everyone who helps us keep these old Macs and hackintoshes moving forward. It's more of a hobby to me and I'm holding on as long as I can for the right Mac to come out to retire my 4,1.

 

[Syncretic]

Joking aside, what are the implications of newer CPU instructions being used in applications? Can an application or program call on RDRAND? If it does, what happens on a system that doesn't have this instruction? Am I right to presume the program just will fail or crash?

Any user-space application can do as it pleases, including using instructions newer than the CPU it's running on. If that happens, a #UD exception is thrown, and that process gets terminated. The real problems occur when such instructions appear in kernel-space (e.g. in a kext, or in the kernel proper) - the #UD condition is considered fatal, and a panic occurs. That's what this patch is trying to avoid.

 

[Dayo]

The patches (you'll want both), which go in the Kernel - Patch array

Perhaps add a note on where these should go in relation to SurPlus ... even if to say this is not relevant?

 

[eVasilis]

Any user-space application can do as it pleases, including using instructions newer than the CPU it's running on. If that happens, a #UD exception is thrown, and that process gets terminated.

In other words, many may end up with systems that boot without issues but dysfunctional or not functional when it comes to apps needed for various work flows, as those may be calling on RDRAND. Potentially, this could affect even the most basic of apps and if apple keeps on bringing such changes then the road ahead is a difficult one.

Or did I get everything wrong?

 

[Bmju]

In other words, many may end up with systems that boot without issues but dysfunctional or not functional when it comes to apps needed for various work flows, as those may be calling on RDRAND. Potentially, this could affect even the most basic of apps and if apple keeps on bringing such changes then the road ahead is a difficult one.

Or did I get everything wrong?

I think the right answer is, @Syncretic has already written instruction emulation patches too https://forums.macrumors.com/thread...emulation-to-enable-amd-metal-driver.2206682/ so if this turned out to affect anything real, then it would also be patchable.

Also, FWIW, a well-behaved app., at least one designed to also run on earlier versions of macOS as well, should probably be checking for which processer it is on to see whether or not to use RDRAND.

Also, possibly worth pointing out that this additional potential issue, which @socamx correctly identified, is not to do with the recent change which Apple have made! Any app could perfectly validly have assumed that the RDRAND instruction should be present under Monterey (since it is, on all officially supported systems...) and used it already, with or without the fact that Apl have started to use it.

 

[Syncretic]

In other words, many may end up with systems that boot without issues but dysfunctional or not functional when it comes to apps needed for various work flows, as those may be calling on RDRAND. Potentially, this could affect even the most basic of apps and if apple keeps on bringing such changes then the road ahead is a difficult one.

Or did I get everything wrong?

The bigger threat to classic Macs has been building for a decade now. AVX was released with Sandy Bridge in 2011, and there's already some application software that requires it (I'm working on solving that problem, too). RDRAND isn't particularly valuable to most application programmers, but AVX (1/2/512) offers a lot of performance advantages in many different environments. Other extensions to the instruction set could also end up causing problems if they start getting used - SHA, TSX, FMA, etc. Fortunately, most application programmers want to appeal to the widest possible audience/market, so they'll aim for the lowest common denominator and avoid the newer features unless they're essential to the product.

 

[JohnD]

VMware (cough), XSAVE.

 

[khronokernel]

For anyone who wants to experiment with 12.1 Beta 1+ through OCLP, we have an RDRAND branch:

• Nightly RDRAND OpenCore Patcher (TUI)

This is the same as Syncretic's patch mentioned in the first post, have verified with a couple machines that the patch results in no noticeable issues however would like others to also comment.

Tested models:

• iMac8,1 - Penryn
• MacBookPro8,2 - Sandy Bridge
• MacPro5,1 - Westmere

Unlikely to be added to mainline till Beta 3+ as I believe there's other changes to XNU we should expect before 12.1's release

Additionally Apple seeded an InstallAssistant for Beta 1 today so can easily flash a USB for testing:

• https://swcdn.apple.com/content/dow...eftt16afva9go9i4u0r5uef0/InstallAssistant.pkg

 

[nandor690]

For anyone who wants to experiment with 12.1 Beta 1+ through OCLP, we have an RDRAND branch:

• Nightly RDRAND OpenCore Patcher (TUI)

This is the same as Syncretic's patch mentioned in the first post, have verified with a couple machines that the patch results in no noticeable issues however would like others to also comment.

Tested models:

• iMac8,1 - Penryn
• MacBookPro8,2 - Sandy Bridge
• MacPro5,1 - Westmere

Unlikely to be added to mainline till Beta 3+ as I believe there's other changes to XNU we should expect before 12.1's release

Additionally Apple seeded an InstallAssistant for Beta 1 today so can easily flash a USB for testing:

• https://swcdn.apple.com/content/dow...eftt16afva9go9i4u0r5uef0/InstallAssistant.pkg

Just updated to OCLP 0.3.2 and am going to try and update to beta through System Preferences on a 12,2 iMac.

 

[MacRumors3590]

WOW, Great job guys!.
Installed 12.1 beta1 with MonteRand/OCLP 0.3.2 on 2 of my 5,1 machines with no issues to speak of at this point!
Re-patched with OCLP 0.3.1(No network connection needed) of course.

Update:
Macbook Pro GT 330M 2010 17" also updated and running great!!

 

[Enricote]

I have successfully updated my two Macs to Monterey 12.1 Beta under the experimental OCLP 0.3.2 Nightly RDRAND Opencore Patcher


1.- MacPro 4,1>5,1
2.- MacBook Pro 4,1 (early 2008)


Thanks again (never enough) to @Syncretic (amazing "in ten minutes solution" to our new booting problem) and all the OCLP team

 

[borp99]

On my Mac Pro 5,1, I tried twice to install 12.1 using the experimental OCLP 0.3.2 Nightly RDRAND Opencore Patcher but each time the installer rebooted to Recovery (rather than the 'xxx min remaining' screen), initially showing the Monterey Recovery selection window in outline only, then (very weirdly) swapping to my Catalina recovery selection window!

I then reinstalled OCLP 0.3.1 and manually added the MonteRand patches (had to use BBEdit, as TextEdit - again weirdly - kept superimposing part of the 'copy and paste' patch text over the top of the SurPlus lines). Although probably not necessary, I used JackLuke's Monterey BaseSystem.fix method to build my USB installer, which unseals the resultant OS. Note: I added the install string AAAAAAAAAAAAAACAAAAAAA== to the CPU1Data and Mask in OCLP, as is my usual method (not sure if it's really necessary but it hasn't failed me yet / remove the string after the OS is up and running, as it apparently causes a 5% reduction in perfomance).

From there, 12.1b1 installed perfectly, with no hard reboots. Everything seems to be working, including BT (which I have feed off an internal USB 2 hub's data wires). So, I'm very impressed and grateful that Syncretic (and any other developers) has come up so quickly with a working fix. We all hope this continues to work with further betas and 12.1+ releases.

This new experimental fix certainly deserves further donations!

 

[Nekapsule]

Amazing work again @Syncretic!
Successfully patched my secondary X58 / Xeon X5675 Hackintosh and upgraded to 12.1 beta seamlessly.

For those manually applying the patch, don't forget to bump your 2 Surplus patches MaxKernel values to 21.2.0 as well in case you still had 21.1.0 there.

 

[matsno]

Is there any solution to apply this patch if the mac stuck to the apple logo after updating itself to 12.1 beta? The model is a Mac Pro 5.1

 

[MacRumors3590]

Is there any solution to apply this patch if the mac stuck to the apple logo after updating itself to 12.1 beta? The model is a Mac Pro 5.1

simply re-install from USB key if the install got hosed.
In some cases for me I had to make sure on 1st restart that I was choosing the correct icon. In my case I believe it said "Install macOS"

 

[TECK]

From a high level, it's just another plot twist in the SurPlus saga, the introduction of rdrand instructions to handle the randomization of internal kernel memory; the patches below just remove the rdrand instructions and use a constant value instead.

From my perspective, these patches should not have a different name and should be added into SurPlus Github repo, since they are directly related. I mean SurPlus emulates the rdrand CPU instruction while these new patches disable the rdrand randomization for a specific case. They are definitely part of SurPlus logic. If you don't think is a good idea, can you please create a new repo then?

I added your patches to Plistlib Generator OC 0.7.5 upgrade PR.

 

[Syncretic]

From my perspective, these patches should be added into SurPlus Github repo, since they are related and also is easier to update the Kernel versions in one place. If you don't think is a good idea, can you please create a new repo?

I added your patches to Plistlib Generator OC 0.7.5 upgrade PR.

Earlier today, I updated the SurPlus repo README to include a reference to this thread, and I increased the SurPlus MaxKernel to 21.2.0. I plan to create a separate repo for MonteRand when I have some time to write it up. In the meantime, sorry for any inconvenience. (As always, I have serious "not enough hours in the day" issues...)

I mean SurPlus emulates the rdrand CPU instruction while these new patches disable the rdrand randomization for a specific case.

Correction: SurPlus doesn't emulate anything, it simply causes MacOS to avoid using CoreCrypto before zalloc is fully initialized.

 

[TECK]

Correction: SurPlus doesn't emulate anything, it simply causes MacOS to avoid using CoreCrypto before zalloc is fully initialized.

Thanks for explaining, I'll update the documentation on my repo with your info. Fixed

 

[MacRumors3590]

The bigger threat to classic Macs has been building for a decade now. AVX was released with Sandy Bridge in 2011, and there's already some application software that requires it (I'm working on solving that problem, too). RDRAND isn't particularly valuable to most application programmers, but AVX (1/2/512) offers a lot of performance advantages in many different environments. Other extensions to the instruction set could also end up causing problems if they start getting used - SHA, TSX, FMA, etc. Fortunately, most application programmers want to appeal to the widest possible audience/market, so they'll aim for the lowest common denominator and avoid the newer features unless they're essential to the product.

I'm really hoping there is something that can be done so we can use AVX apps on our unsupported macs because even though there's not a huge amount of AVX apps that i would use, there is one in particular as a musician I could really use, and that's IK Multimedia's "MODO DRUMS"
Thanks!

 

[Forrhouse]

I too hope there is something that can be done so we can use AVX apps. I also, have a couple apps that require AVX.
I got them as part of a bundle I purchased. I'm using a MacPro5,1 2x 6-Core Intel Xeon 3.46 GHz 48gigs of Ram and Rx580. I'm hoping this will be possible on Big Sur 11.2.3 and up as some of my software is still not Monterey compatible. When all of my apps become Monterey compatible then I will move to that.

 

[h9826790]

I too hope there is something that can be done so we can use AVX apps. I also, have a couple apps that require AVX.
I got them as part of a bundle I purchased. I'm using a MacPro5,1 2x 6-Core Intel Xeon 3.46 GHz 48gigs of Ram and Rx580. I'm hoping this will be possible on Big Sur 11.2.3 and up as some of my software is still not Monterey compatible. When all of my apps become Monterey compatible then I will move to that.

Looking for AVX/AVX2 software failures

I'm looking for samples of MacOS-based software that fails to run on Mac Pro 3,1/4,1/5,1 (or others) because it contains AVX/AVX2 instructions. The failure can be early and polite, such as an installer refusing to complete because it thinks the CPU doesn't have those instructions, or it can be...

forums.macrumors.com

 

[Forrhouse]

Looking for AVX/AVX2 software failures

I'm looking for samples of MacOS-based software that fails to run on Mac Pro 3,1/4,1/5,1 (or others) because it contains AVX/AVX2 instructions. The failure can be early and polite, such as an installer refusing to complete because it thinks the CPU doesn't have those instructions, or it can be...

forums.macrumors.com

@h9826790 The links below are for 2 programs that Need AVX to work. You can download the demo installers on these pages.​

MODO DRUM

UNO DRUM - True analog/PCM drum machine. Easily programmable. Ultra-portable.

www.ikmultimedia.com

ARC Studio

ARC Studio. Advanced Room Correction System.

www.ikmultimedia.com

 

[jackluke]

Hello @Syncretic , if you recall we had conversations some months ago and also you made on my request telemetrap, so I already knew your expert advanced skills in this field.

While my machines don’t required Latebloom (though I tested to delay booting and no issues) and SurPlus, from 12.1 beta1 kernel ≥ 21.2.x instead your new MonteRand patch is totally required.

I have low knowledge of that stuff you explained, but when I read a documentation I understand a bit of something, so with your MonteRand through OpenCore you are patching the kernel binary in RAM, so I simply adapted or converted your OC patch to a binary patch, but not directly on kernel file (as you can notice from picture the modified date is still stock apple 26 October) rather on its Preboot BKE kc that essentially already embeds the uncompressed LZFSE kernel and doesn't even require to rebuild a new kc with the patched kernel, so I summarised as this example:

sudo perl -pi -e 's|\x0f\xc7\xf1\x73\xfb\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|\x31\xc9\x90\x90\x90\x21\xf1\x39\xd1\x73\xf5\x89\xc9\x48\x8b\x94\xcd\xd0\xfd\xff\xff|g' /path/BootKernelExtensions.kc

sudo perl -pi -e 's|\x0f\xc7\xf2\x73\xfb\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|\x31\xd2\x90\x90\x90\x83\xe2\x0f\x83\xfa\x07\x77\xf3\x0f\xb7\x34\x41|g' /path/BootKernelExtensions.kc

of course this can be also applied directly to the kernel file but this implies to rebuild kmutil kc and a new snapshot from an external Recovery environment.

Tested your patch on same external USB disk with MacBook7,1 and MacBookPro6,2 (dualGPUs) and properly worked.

Thanks for your incredible work.