Supporting Spoofless Usage

[khronokernel]

Currently with OpenCore Legacy Patcher, we use a minimal spoof approach to achieve native OS updates and installations. However as we've maintained this project, a spoofing approach has brought a numerous amounts of "hacks" to work around Apple's hard coded logic within kexts.

Moving forward, we should look to a spoofless approach in where we enforce a Virtual machine like enviroment allowing us to use our original SMBIOS while still allowing for native installer and OTA support.

Parrotgeek1's VMM patch set would force kern.hv_vmm_present to always return True. With hv_vmm_present returning True, both OSInstallerSetupInternal and SoftwareUpdateCore will set the VMM-x86_64 board ID while the rest of the OS will continue with the original ID.

• Patching kern.hv_vmm_present over manually setting the VMM CPUID allows for native features such as CPU and GPU power management

A current draft of this project can be found on the vmm branch

Benefits of VMM approach

• Maintains native macOS Installers and OTA updates
• Reduced number of patches to work around our SMBIOS spoof
• Allows stock HD3000 kext usage
• Reduce failure points during boot
• MacBook8,1 installer fix

Drawbacks of VMM approach

OS Support limited to Big Sur and newer

This is due to 2 reasons:

• OSInstallerSetupInternal and SUCore added the hv_vmm_present check with Big Sur, older OSes rely on probing the CPUID directly
• hv_vmm_present is only present in XNU 20.4.0+
  • macOS 11.2.3 and older and excluded, however SurPlus negates the need for older macOS Big Sur builds

Potentially we can write a Lilu plugin to force isVirtualMachine to return true, however for older OS we're unlikely to justify the engineering efforts at least for the time being.

Only applicable for Kernel Space

As hv_vmm_present is generated in the kernel, boot.efi must do it's own probe for CPUID. This adds another area where we must patch, either by setting HWBID to a newer model in NVRAM or patching out the Board ID check entirely.

• Usage of -no_compat_check is not ideal as Single User mode will ignore the argument

No support for H.265 with Polaris+ GPUs

macOS's graphics stack assumes only iMacPro1,1 and MacPro7,1 support Polaris+ for hardware decode, usage of a machine's original SMBIOS with an upgrade GPU will result in feature loss.

Because of this, we will likely add new defaults for hardware probing to set minimal spoof when a Polaris or newer GPU is found.

Hardware-based License Keys breaking

As we switch to a no spoof environment, software tied to users hardware will need to request new keys. However this is expected with each macOS release regardless

Potentially unmasking new issues within macOS

As nearly the entirety of our testing and validation for the past year has been done on minimal spoofed machines, we'll need to do extensive validation

[khronokernel]

Testing has showed that the VMM branch is quite reliable, plans to be merged into mainline with 0.3.1.

Currently to allow for merging into mainline, we'll need to adjust some things:

• Add RestrictEvents usage for unspoofed MacBookPro10,1
• Add VMM patch for models of T2 SMBIOS spoofs that require root volume patching

[khronokernel]

VMM Usage Notes

Run down on quirks users should keep in mind when using a spoofless system:

• Requires macOS 11.3 or newer
  • For 11.2.3 and older use Minimal or higher spoofing
• Certain applications may need to be re-authorized as they think the machine has been changed
• Macs with upgraded AMD Polaris dGPUs will default to Minimal to ensure H.265 support
• macOS Monterey Betas will not see macOS updates till 12.1 Beta is seeded
  • Apple issue affecting supported Virtual Machines as well, updating via InstallAssistants to get to 12.0.1 is recommended
• Certain OCLP features such as CPU renaming will be non-functional due to the lack of SMBIOS spoofing
  • Functionality can be restored by selecting Minimal spoof (or higher) in SMBIOS settings
• HD3000 Macs must unpatch their root volume before updating (or reinstall with data intact)
  • This is due to the HD3000 acceleration kexts having Board ID hard coded in, rerunning OCLP's root patcher after booting VMM will resolve this
  • Minimal spoof will revert this need

[khronokernel]

699ccd5