Quick look at macOS Rapid Security Response

Note: most of this post applies to iOS 16 too.

Since macOS Ventura, Rapid Security Response is supported. This allows for lightweight updates that do not involve going through the full upgrading flow. It also allows for smaller operating system installs.

cryptex

The cryptex (CRYPTographically-sealed EXtension) additional images are stored in DMGs and are an extension of an existing volume. There are two cryptex images present on Apple OSes being released this fall, App and OS.

Currently, support for 3rd-party cryptex images is not planned on macOS. Cryptex was first used for the iPhone Security Research Device, as a way to add additional binaries with custom entitlements.

As described by Apple, cryptex(es) not being visible to mount(8) is a design decision:

Cryptexes are not visible in the mount lists since they are not mounted.

Cryptexes are extensions of an existing volume and should be treated as such, therefore they do not get listed in the mount list.

Answer from Apple to FB10135388

App cryptex

The app cryptex contains Safari (and the password pane), which are no longer in the data volume.

OS cryptex

The OS cryptex contains the dyld shared caches and some additional libraries.

Those libraries are often related to Safari, but also include some others, including libstdc++.dylib.

The list of the (partially or fully) included application frameworks outside of the dyld shared cache, often resources only, for a macOS target:

OpenGL.framework
HelloWorldMacHelper.framework
WebKit.framework
_AuthenticationServices_SwiftUI.framework
AuthenticationServices.framework
PasswordManagerUI.framework
JavaScriptCore.framework
SafariServices.framework
SafariShared.framework
SafariSharedUI.framework
SafariFoundation.framework
WebBookmarks.framework
WebDriver.framework
Safari.framework
WebGPU.framework

dyld shared cache

As macOS Ventura only supports machines with AVX2, the x86_64 and arm64e dyld shared caches are no longer present on macOS installations for Intel processors, as they are unused there. Apple Silicon installations will also not get an unused x86_64h slice anymore.

Notably, the x86_64 dyld shared cache remains compiled for Apple Silicon machines as Rosetta does not support AVX(2).

As such, this design allows to save hard disk space in addition of allowing components to be updatable without breaking the seal for the system volume.

Mount paths

Currently, cryptex contents are accessible via /System/Cryptexes/{OS,App}. Platform specific mount points are /private/preboot/Cryptexes/{OS, App} for iOS/tvOS/iPadOS/realityOS/… and /System/Volumes/Preboot/Cryptexes/{OS,App} for macOS.

On macOS, the current cryptex DMGs are stored on /System/Volumes/Preboot/[Volume Group UUID]/cryptex1/current together with the corresponding trust caches and personalisation information.

BootPolicy (Apple Silicon only)

A new BootPolicy element, spih, representing the Cryptex1 Image4 Hash was added in macOS Ventura. This makes the Cryptex hashes part of the Secure Boot trust chain.

Conclusion

By separating some of the most often upgraded components to outside of the sealed system volume, Apple makes rolling out updates a less heavyweight process.

This is good from the user perspective. It allows Apple to remove most of the downtime associated with OS update when a full one isn’t needed.