macOS 12.0 Beta 6 SecureBoot requirements for T2 models

[khronokernel]

With macOS 12.0 Beta 6 (21A5506j), Apple changed what data is passed through Pallas to receive deltas. Previously only the machine's Board ID was passed through, however with Beta 6 and newer, Pallas now requests the T2 model ID on all models that ship with a T2.

The problem with this is that currently OpenCore only supports x86legacy identifier for macOS Monterey, as all other T2 IDs will fail to install or update. Passing x86legacy will not allow OTA updates on these T2 models.

• Additionally x86legacy will no longer work on OS updates or installs with beta 6, failing in the same way that T2 IDs failed in the early Monterey betas

Affected Models

This issue currently affects the following models:

• MacBookAir8,x+
• MacBookPro15,x+
• Macmini8,1
• iMac20,x
• iMacPro1,1
• MacPro7,1

Older models do not include a T2 and thus macOS supports OTA solely with the board ID passed through.

Current Concerns

Main questions that need to be answered:

• Where does Pallas pull the T2 ID from
• Does this issue affect older versions of Monterey, or only introduced with Beta 5 updating to Beta 6 or newer
• Can the T2 ID be spoofed solely for Pallas

Additionally the following models currently use a T2-based SMBIOS for Monterey:

• MacPro3,1-5,1
• Xserve2,1-3,1
• iMac7,1-12,x

Possible alternative for these models would be iMac19,1 as this SMBIOS has been known to provide hardware acceleration for Polaris+ GPUs in many cases. Needs further investigation

• Users can manually change OCLP's SMBIOS via Advanced Patch Settings -> Override SMBIOS Spoof -> User Override -> iMac19,1

Current Work-arounds

The main 2 known work arounds currently:

• Use a non-T2 SMBIOS
• Boot an installed Monterey with a T2 SecureBootModel ID
  • Download and prepare the update
  • Once ready to reboot, disable SecureBootModel and let OS update continue

[parrotgeek1]

I have noticed that gdmf.apple.com / Pallas is also no longer returning any Monterey updates for the pseudo-board-ID "VMM-x86_64". This completely breaks software updates in VMs, because this board ID is used if the VMM flag is detected in CPUID. Could someone file a Radar for this please?

To answer some of your questions:

The data sent by the OS have not changed. The issue seems to be server side - beta 1 will not see beta 6 in a VM either.

[dhinakg]

VMM-x86_64

In what exact case is this used? All times when the VMM flag is present?

And what exactly are you using to reproduce?

[parrotgeek1]

This is used in a VM (or with VMM spoofing). if the value of sysctl kern.hv_vmm_present is 1 it will use this instead of the actual board ID. Check OSInstallerSetupInternal.framework inside the installer app in Hopper (search for hv_vmm_present).

Amusingly, there is also an explicit check for the opencore-version nvram variable as well, to force the Mac platform to be unknown rather than legacy. It's in ___BIDeviceInfoGetMacPlatform_block_invoke.

By the way, it's possible to intercept exactly what it's sending to gdmf.apple.com using "sudo defaults write com.apple.MobileAsset PallasUrlOverrideV2 <url that's not https>". If you use https it will fail because it enforces cert pinning. SIP does not need to be disabled.

[khronokernel]

That's alright with us, if you're ok we have a Discord server:

• https://discord.gg/rqdPgH8xSN

We made a private channel hidden from others so just ping DhinakG#9721 or myself (MykolaG#7153) and we can add you there