macOS Ventura and OpenCore Legacy Patcher Support

[khronokernel]

This page will be updated as we learn more about Ventura and the changes within.

• If you're not an active developer for legacy Macs, DO NOT INSTALL VENTURA. Even if you're bored, more random users installing the beta create more noise and thus more difficult to properly develop patch sets.

• Know that this is an early developer beta and that hardware bricks can happen and be unrecoverable. Only continue on if you're alright flushing the hardware down the drain.

---

With the initial developer beta, we're seeing many changes to the OS that affect our work with OpenCore Legacy Patcher. Some of these include:

• Removal of all pre-Kaby Lake models
• Removal of pre-AVX2.0 dyld shared cache
• Removal of on-disk binaries for kexts in /System/Library/Extensions
• Removal of Haswell, Broadwell, Skylake, and AMD GCN 1-3 graphics stack
• Removal of UHCI/OHCI USB stack
• Removal of USB Maps for older units
• Removal of Intel Ethernet support
• Removal of Pre-Force Touch Trackpad support
• Library Validation and AMFI changes
• Boot issues on MacPro6,1
• Broken Power Management on Ivy Bridge and older
• Broken Wireless Patches for legacy Wifi Cards
• FeatureUnlock race condition
• Advanced Data Protection unsupported on patched Macs

Removal of all pre-Kaby Lake models

This release removes the following models:

• MacBookPro11,4/5, MacBookPro12,1, MacBookPro13,x
• MacBookAir7,x
• MacBook9,1
• Macmini7,1
• MacPro6,1
• iMac16,x, iMac17,1

Removal of pre-AVX2.0 dyld shared cache

With the discontinuation of OS support for the MacPro6,1 (Trash Can), Apple no longer has any reason to retain pre-Haswell support in macOS. This means that important parts of macOS, namely the dyld shared cache, no longer ship a non-AVX2.0 variant on Intel.

However, as we expected, Apple didn't update Rosetta to support AVX2.0 and thus has given us a partial back door with Rosetta's dyld shared cache.

With Ventura, the shared cache is now off of the Root volume and instead inside the Preboot volume. Thus the Rosetta cache is not available to us if it wasn't installed during the installation.

• The goal to move the dyld cache to Preboot seems to be to allow for quicker security updates as well as reduce the total size of the on-disk installation by creating more architectural-specific installations.

With the advent of CryptexFixup.kext, Rosetta Cryptex will now automatically be installed during OS installs and updates. Information below is now for reference purposes.

• OpenCore Legacy Patcher v0.5.0 (commit 4ef2c00) and newer includes CryptexFixup.kext

Manual Method

To rip the non-AVX2.0 cache on Apple Silicon, there are 2 methods:

• Rip from an active Apple Silicon installation
• Extract from an Apple Silicon IPSW

The methods are listed in one of the attached comments.

• Extracting the non-AVX2.0 dyld shared cache

Once you have acquired the correct OS.dmg, apply them to the Intel installation at /System/Volumes/Preboot/{Ventura Preboot UUID}/cryptex1/current (remember to find the correct UUID for the Intel install, as each UUID is unique to each installation)

• Ensure the disk image is renamed to OS.dmg if you extracted from the IPSW

Finally, swapping dyld shared caches in Preboot will trigger a kernel panic during Root Hash verification. OpenCore Legacy Patcher will enable a patch to skip this check:

03b8b46#diff-e6e31b873ed817965dd126ab9dd4ff17d91e0b0ed49dc87f1ecd0c89bebd9a1dR1688-R1717

• As mentioned above, CryptexFixup will also handle the APFS patch for end users

Removal of on-disk binaries for kexts in /System/Library/Extensions

Similar to how iOS has been for several years, Ventura has now removed the on-disk binaries inside of kexts in /System/Library/Extensions. Now instead, developers are required to download and install the Kernel Debug Kit from Apple's Developer Site anytime they wish to create a new Boot and System Kernel Collection.

• Kernel Debug Kits require an Apple account to access, however free accounts are supported

Due to the nature of Root Volume patching in OpenCore Legacy Patcher, we cannot automate this without rehosting files and requiring a network connection during root patching. We will be researching more, however, for the initial beta cycle, we expect to require KDKs to be installed by the end-user before running.

Additionally Kernel Debug Kits are per-build specific, as using an older build will mean using older kernels, etc. kmutil does support mismatched KDKs however realitically this should be avoided under all circumstances.

Removal of Haswell, Broadwell, Skylake, and AMD GCN 1-3 graphics stack

As expected, Apple has also removed graphics support for Haswell through Skylake as well as GCN1 through 3. Unfortunately, there seem to have also been changes to the Metal stack, that have broken support for older Metal graphics including all those most recently dropped.

A framebuffer is easily achieved by re-adding the extensions, however, Metal will take some development time to achieve. Ventura has changed much of the Metal stack, meaning we need to learn a whole new part of macOS's graphics stack to re-implement support for older cards.

• In future documents, we'll be referencing pre-Ventura Metal drivers as "Legacy Metal" for simplicity.

And as a reminder to the .bundle situation, Apple no longer ships true .bundle files on-disk anymore. Instead, they're hollow files where the actual binaries are located within the dyld shared cache. The last time these binaries were on-disk was with macOS 11.0 20A5364e (Beta 6).

Regarding using other binaries from the dyld shared cache, you'll need to grab the binaries from a RAM disk that's shipped with OS installers and updaters. The RAM disk is located under the SharedSupport.dmg:

/Applications/Install macOS.app/Contents/SharedSupport/SharedSupport.dmg:
   /Volumes/Shared Support/com_apple_MobileAsset_MacSoftwareUpdate/{random string of hex}.zip (size is about 12GB~):
      {random string of hex}/AssetData/usr/standalone/update/ramdisk/x86_64SURamDisk.dmg

Early research notes attached with regards to Ventura acceleration:

• https://github.com/khronokernel/khronokernel.github.io/blob/legacy-metal/_posts/2022-08-01-2022-LEGACY-METAL.md

---

With regards to the introduction to Metal 3, this has little effect on us. Metal 3 is just an API feature set, and is actually limited to newer GPUs only:

GPU Architecture	Support
Intel Kaby Lake	Metal 2
Intel Coffee Lake	Metal 3
Intel Ice Lake	Metal 3
AMD Polaris	Metal 2
AMD Vega	Metal 3
AMD Navi	Metal 3

Removal of UHCI/OHCI USB stack

Currently Apple has removed the following drivers:

IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBOHCI.kext
IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBOHCIPCI.kext
IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBUHCI.kext
IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBUHCIPCI.kext

They will need to be reinjected to resolve USB 1.1 support for pre-Ivy Bridge units.

• Reminder on Penryn units, Keyboard and Trackpad are wired through the USB1.1 controller thus breaking support.

Removal of USB Maps for older units

Now all units need a USB map provided, as Apple has removed the remaining units:

/System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/AppleUSBHostPlatformProperties.kext/Contents/Info.plist

Removal of Intel Ethernet support

Following Network Drivers have been removed:

• AppleIntel8254XEthernet.kext
• Intel82574L.kext
• AppleIntelI210Ethernet.kext (transitioned to DriverKit)

Removal of Pre-Force Touch Trackpad support

Following kexts were removed:

• AppleUSBTopCase.kext
• AppleUSBMultitouch.kext

Re-injecting both kexts restores pre-Force Touch trackpad support

Library Validation and AMFI changes

With Ventura, our _cs_require_lv patch broke which we rely on to pass our shim'd binaries as allowable in macOS under their security policy. In addition to our patch breaking, Apple has modified the requirements for disabling AMFI outright.

With Ventura, AMFI can no longer be disabled in Safe Mode, as well when CSR_ALLOW_UNTRUSTED_KEXTS is not toggled (we assume this is related to DriverKit). Thus to disable Library Validation and AMFI in general, you'll need:

• Bit 0x1 flipped in SIP
• amfi_get_out_of_my_way=0x1 in boot-args

We will be researching what other patches can be used in the future to alleviate this.

Boot issues on MacPro6,1

With macOS Ventura, Apple has changed some early init logic that has broken support for MacPro6,1. Currently no known work-around is available for these units.

More information can be found below:

• Ventura Boot Issues with certain GPU/Firmware combinations

Broken Power Management on Ivy Bridge and older

Odd issue experienced on pre-Haswell machines is broken power management. Specifically machines will be stuck at their base clock, and will not boost or idle correctly.

Looking at IOService, we can see that the X86PlatformPlugin (or ACPI_SMC_Platform_Plugin on Sandy Bridge and older) no longer publish CPUPLimitDict and IdlePlimitDict entries. Downgrading IOPlatformPluginFamily.kext does not seem to resolve, further research required.

Power management resolved by removing intel_cpupm_matching check in AppleIntelCPUPowerManagement.kext

Broken Wireless Patches for legacy Wifi Cards

• Atheros: All models
• Broadcom: BCM94328 and BCM94322

Support has been resolved in OpenCore Legacy Patcher v0.5.4

FeatureUnlock race condition

With macOS Ventura, currently there's a race condition with userspace patching on slower hardware. At this time, we'd recommend staying on macOS Monterey if you need any features provided by FeatureUnlock.

• Newer hardware generally won't experience this issue

Advanced Data Protection unsupported on patched Macs

Due to the inherit nature of patching a Mac to a newer OS, Apple's Advanced Data Protection system is unsupported on machines being patched with OpenCore Legacy Patcher. If this machine is important to you, you can disable Advanced Data Protection:

• https://support.apple.com/HT212520

Overall estimate time for support

Looking at all the issues in front of us, I don't believe there's any short term possible fixes for the community to use. Best time frame would be 6 months from now when a proper build of OpenCore Legacy Patcher can be released, but even this is difficult to promise.

[flagersgit]

Additional information about Cryptexes

As you have read in the OP, a cryptex contains the dyld shared cache and other smaller parts of userspace.
Apple intends for cryptex updates to be used for their new "Rapid Security Response" feature as a reintroduction of simple monthly updates to userspace that we were used to with Catalina and older.

Because of this, the cryptex can be automatically swapped from the ARM64e cryptex to x86_64h during a reboot as part of the update flow, and thus break booting on non-AVX2 systems.

For this reason, we recommend disabling the "Install system data files and security updates" option in System Settings for the time being until we determine what is the best way to resolve this problem.

With the advent of CryptexFixup.kext, this should no longer be a concern.

[flagersgit]

non-Metal Information

Regarding non-Metal, the team is hard at work to get non-Metal working, however this is our greatest challenge since Big Sur.

Apple has made significant changes to the graphics stack in order to facilitate fancy effects, and particularly, Stage Manager. We will update you as we work on development, however, now is not the best time to ask about ETAs.

Framebuffer, as with past OSes and Legacy Metal, was the first milestone we achieved, however accel is still fairly far away (same general timeframe as Mykola mentioned above).

When we have something to show, it will be either here or in a release of OCLP when the time comes.

[khronokernel]

Extracting the non-AVX2.0 dyld shared cache

With the advent of CryptexFixup, users will no longer need to manually extract the Rosetta Cryptex. Below is simply for reference and research purposes.

---

As mentioned above, Ventura no longer ships with a non-AVX2.0 dyld shared cache on Intel. However Apple Silicon installs do retain pre-AVX2.0 dyld's. These dyld's are located in a disk image called OS.dmg.

Currently there are 2 straight forward methods to obtain it:

• Extract OS.dmg from an Apple Silicon IPSW
• Rip OS.dmg from active Apple Silicon installation

Extract OS.dmg from an Apple Silicon IPSW

The simplest way to extract the OS.dmg is to download the IPSW listed on Apple's Developer Portal and grab the correct beta you'd like (labeled Mac computers with the Apple silicon). Next, rename the .ipsw to .zip and extract.

You'll see a 4GB~ disk image, mount it and it should be labeled as arm64e Cryptex, this is how you can verify it's correct.

Dev Portal	Extracted	Mounted and verified

---

Rip OS.dmg from active Apple Silicon installation

With an Apple Silicon Mac with Ventura Installed, navigate to the Preboot volume and find the associated Ventura folder.

• Use the SystemVersion.plist in the same folder to verify the Preboot UUID is for the correct OS

/System/Volumes/Preboot/{Ventura Preboot UUID}/cryptex1/current:
  - os.dmg

[crystall1nedev]

Native Graphics Stack with pre-Haswell hardware

As mentioned in the above posts, the discontinuation of OS support for the MacPro6,1 has meant Apple is no longer required to support pre-AVX2.0 binaries. One of these areas is with the remaining native AMD graphics stack.

The main area of concern is with the userspace portions of the AMD stack, namely the following binaries located inside the OS.dmg that have been compiled explicitly as x86_64h:

AMDShared.bundle
AMDMTLBronzeDriver.bundle
AMDRadeonVADriver.bundle
AMDRadeonVADriver2.bundle
AMDRadeonX4000GLDriver.bundle
AMDRadeonX5000GLDriver.bundle
AMDRadeonX5000MTLDriver.bundle
AMDRadeonX5000Shared.bundle
AMDRadeonX6000GLDriver.bundle
AMDRadeonX6000MTLDriver.bundle
AMDRadeonX6000Shared.bundle

• Kernel space may also ramp up AVX2.0 usage as betas continue
• Additional notes by Syncretic regarding AVX1.0 and 2.0 in Ventura

Due to this, machines that lack the AVX2.0 instructions (ie. pre-Haswell CPUs) can no longer use native GPUs in Ventura as-is. The main affected units would be all discontinued Mac Pros, as they can no longer use socketed cards or eGPUs to retain native graphics acceleration.

• Models include: MacPro3,1, MacPro4,1, MacPro5,1, MacPro6,1

• The main models that could theoretically use native GPUs under normal circumstances would be late 2013 and newer iMacs and 2014 Mac mini via eGPUs

  • iMacs would need to drive an external display if using eGPU, internal display cannot be accelerated with an eGPU without modding
  • Haswell and newer laptops could also fall under this group, however less practical for non-stationary systems.

---

Graphics architectures that rely on AVX2.0 in Ventura:

• AMD Polaris (RX400/500)
• AMD Vega (48/56/64/VII)
• AMD Navi (RX5000/6000)

---

With OpenCore Legacy Patcher v0.5.4, AMD Polaris and Vega GPUs can be patched to support pre-AVX2.0 hardware. AMD Navi Graphics Cards are still currently unsupported.

[khronokernel]

Alpha Support for macOS Ventura

With the recent success of graphics acceleration on macOS Ventura, we'll trying to get OpenCore Legacy Patcher prepared for public testing hopefully soon. However as Ventura has changed much of the patcher landscape for us, there's still some critical issues we'll need to work through to get the current patcher working.

• Graphics Acceleration
• KDK Requirements
• Misc Requirements

Graphics Acceleration

Legacy Metal

With the advent of ASentientBot's DSCE, we've been able to restore legacy Metal support for many Macs in Ventura!

Currently we've been able to verify the following GPU architectures as functional in Ventura:

• AMD GCN 1, 2 and 3
• Nvidia Kepler
• Intel Ivy Bridge, Haswell, Broadwell, Skylake

Issues have been moved to a dedicated issue:

• Legacy Metal Graphics Support and macOS Ventura - Sequoia #1008

Non-Metal

As of this writing, we currently have zero support for machines with non-Metal GPUs.

With the introduction of Stage Manager, Apple implemented a new layer called "WindowManager" that handles window occlusion, spaces, and such. Because this moves much of the logic from SkyLight into WindowManager, and is triggered via XPC calls, non-Metal's SkyLight from Mojave will not work as-is. The team will need to re-implement SkyLight to WindowManager interaction if we wish to support non-Metal on Ventura.

No time estimate can be given for this.

KDK Requirements

Ventura drops on-disk kernel extensions, so users will be required to download and install Kernel Debug Kits from Apple manually. These can be retrieved at Apple's Dev Portal

• Note: KDKs will require an Apple ID to download, free accounts will work fine.

An alternative KDK-less method was implemented with commit b105a73, this allows Metal-based Intel and Nvidia GPU users to omit the KDK requirement and install into the Auxiliary Cache

• Currently AMD GCN 1-3 will still be required to install a KDK due to downgrade requirements

Misc Requirements

Thus for the time being, these units will be properly supported with the Patcher on Ventura:

• iMac13,x+
• MacBook8,1+
• MacBookAir5,x+
• MacBookPro9,x+
• Macmini6,1+

Older machines may experiment with Ventura, however know the following are unsupported:

• Broken USB 1.1 on pre-Sandy Bridge
• Zero non-Metal Graphics support
• Cannot boot MacPro6,1 on Ventura
  • Reference: Ventura Boot Issues with certain GPU/Firmware combinations