Rapid Security Response with legacy Macs

[khronokernel]

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 update
  • Resolved with OCLP 0.5.4
  • Cause: Rapid Security Response with legacy Macs #1019 (comment)
• Pre-Haswell Macs cannot install RSRs
  • This is due to the Rosetta Cryptex being used, while Apple is distributing x86_64h RSRs
• KDKless installs result in WindowServer crashing after RSR installs
  • Resolved with OCLP 0.5.3, applicable for Macs with Intel Ivy bridge, Haswell or Nvidia Kepler GPUs

At 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.

[khronokernel]

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():

• https://github.com/apple-oss-distributions/xnu/blob/xnu-8792.61.2/libkern/c%2B%2B/OSKext.cpp#L14006

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 -nokcmismatchpanic boot-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.

[khronokernel]

macOS 13.3.1 (a) Installation Issues

Unfortunately with yesterday's Rapid Security Response, Haswell Macs (and likely others) cannot boot after applying the update. Specifically the graphics driver in the Auxiliary Kernel Collection kernel panics shortly after KDKlessWorkaround determines the MTL binaries are missing from root:

User facing error	Kernel Panic (hidden)

We believe this issue is likely a race condition caused by AppleIntelHD5000Graphics, however exact cause is unknown.

Due to a bug in the Haswell graphics stack, OpenCore Legacy Patcher 0.6.5 resolves this.

Work-around

Proper Fix: Root patch with OCLP 0.6.5

Work-around for pre-0.6.5 systems:

One can simply disable the problematic kexts from loading by booting in Safe Mode (Cmd+X in the boot menu). Once booted, repatch macOS with OpenCore Legacy Patcher and the issue will be resolved.