khronokernel
commented
1 year ago RSRs with Haswell+ Macs and KDK Installs
- Update: Support has been resolved in OCLP 0.5.4
As initially suspected, now validated, Apple desyncs the Kernel Collections present in macOS when an RSR is installed. Due to this, machines will no longer boot due to their mismatched kernel caches.
Affected Macs
Currently the only affected Macs in OCLP are those with AMD Graphics Patches, as we need to downgrade the AMD Graphics Stack to support the older hardware.
Models include:
- iMac15,1
- iMac17,1
- MacBookPro11,5
- MacBookPro13,3
Prefix: Kernel Collection Understanding and why RSRs break macOS
In macOS there are 3 types of Kernel Collections, each used at a different stage of the boot process that loads the kernel and kernel extensions required by macOS:
- Boot Kernel Collection
- Resides on the Preboot Volume
- Holds macOS's kernel and essential kernel extensions
- Cache used by KDK Macs
- System Kernel Collection
- Resides on the System Volume
- Holds important kernel extensions for Graphics, Audio and misc userspace components
- Cache used by KDK Macs
- Auxiliary Kernel Collection
- Resides on the Data Volume
- Holds 3rd party and user-installed kernel extensions
- Sole cache used by KDK-less Macs
The distinction of these 3 caches location is important as it plays to how Apple implemented the RSR system. On Macs with broken APFS Seals, the Software Update framework will request APFS.kext to revert the APFS snapshot to the last sealed variant. However contrary to the logic used by Apple's own /usr/sbin/bless utility, Software Update forgets to revert the changes present on the Preboot or Data volume.
When this happens, the UUIDs of the Kernel Collections will become mismatched and result in a kernel panic within XNU's OSKext::validateKCUUIDfromPrelinkInfo():
For systems relying on KDK-less usage, macOS is able to easily recover since the 2 essential caches, Boot and System, are still in-sync. However for systems using the KDK approach, we see that the custom BootKC and stock SysKC are in use.
- While XNU does support the
-nokcmismatchpanicboot-arg to suppress panics, the SysKC has hard coded offsets to the BootKC meaning that systems are still unbootable afterwards.
Recovering from an RSR update on a Haswell+ Mac using KDKs
To recover a broken installation, users will need to boot into Single User Mode and repair the Preboot volume manually.
To enter Single User Mode, hold Cmd + S before entering macOS Ventura in OpenCore's Picker.
Once loaded into Single User Mode, you'll be presented with a basic terminal allowing you to run basic commands. For this you'll need to run the following:
# Get the APFS Preboot UUID
ls /System/Volumes/Preboot
# This will list a number of folders, look for those matching this format:
# 00000000-0000-0000-0000-000000000000
# If you only have Ventura installed, 1 UUID will be present
# Check each UUID folder to see which is Ventura
cat ls /System/Volumes/Preboot/4E1B280E-8AB5-48DD-94A1-414505E6D576/System/Library/CoreServices/SystemVersion.plist
# Look for ProductVersion string
# <key>ProductVersion</key>
# <string>13.2</string>
# Once correct UUID found, remove bad KC:
mv /System/Volumes/Preboot/4E1B280E-8AB5-48DD-94A1-414505E6D576/boot/System/Library/KernelCollections/BootKernelExtensions.kc /System/Volumes/Preboot/4E1B280E-8AB5-48DD-94A1-414505E6D576/boot/System/Library/KernelCollections/BootKernelExtensions.kc.BAD
# Install good KC:
cp /System/Library/KernelCollections/BootKernelExtensions.kc /System/Volumes/Preboot/4E1B280E-8AB5-48DD-94A1-414505E6D576/boot/System/Library/KernelCollections/Potential Solutions
Currently still being investigated, however most ideal solution would be to implement either a kernel function or boot script to validate KC UUIDs and fix when required. No time frame can be given to if/when this can be properly developed.
Additionally this issue has been filed to Apple as this affects genuine macOS developers using Kernel Debug Kits:
- Feedback FB11922639: Installing a Rapid Security Response Update only partially reverts Root Volume edits
However unknown whether Apple will leave this as an edge case and ignore.
With the initial beta of macOS 13.2 (22D5027d), Apple has seeded a test update using the new Rapid Security Response System, generally abbreviated as RSR.
RSR relies on the Cryptex system, where core userspace binaries are stored in the Preboot volume, including the DYLD Shared Cache. when macOS performs an RSR-based update, it applies a diff onto the os.dmg and app.dmg. Once applied, a relaunch of the affected application will work however full OS reboot is required for dyld and framework updates.
With legacy Macs running OpenCore Legacy Patcher, the main issues we see are:
Root Patched Macs via KDK approach will result in a crash on updateCause: https://github.com/dortania/OpenCore-Legacy-Patcher/issues/1019#issuecomment-1372557874x86_64hRSRsKDKless installs result in WindowServer crashing after RSR installsAt this time, we'd advise users with either pre-Haswell CPUs to hold off on installing macOS 13.2's Rapid Security Response Update until more information is known.