How might Ventura’s Rapid Security Response work?

One of the more enigmatic features announced for Ventura is Rapid Security Response (RSR), described as:
“Get important security improvements to your devices even faster. This isn’t a standard software update. These improvements can be applied automatically between normal updates — without a restart.”
As far as I can tell, Apple hasn’t released any further details at WWDC. This article looks at what this is likely to mean, and what it probably won’t be able to do.

As far as security patches to macOS go, their biggest barrier is Secure Boot and the signed and sealed System volume (SSV). To apply any update to the contents of the SSV:

  • replacement files have to be installed on the System volume, which is normally unmounted;
  • all changed sections of the file system require fresh cryptographic hashes to be recalculated and saved as seals in a tree;
  • the top-level seal has to be signed (turned into another hash) and saved;
  • that signed and sealed volume must next be turned into a snapshot;
  • the Mac must then reboot from that signed and sealed snapshot.

That – and the requirement to update large dylib and other caches – determines the size and effort required for even minor security patches to Big Sur and Monterey.

So how might Apple change this to enable small patches to be applied “without a restart”, short of abandoning the SSV?

The only practical way is to install those patches outside the SSV. macOS already does this for some of its bundled components, such as Safari, which has been installed on the Data volume, together with components which are changed with security data updates, such as XProtect data and MRT.

However, the Data volume isn’t a good place to keep patches to sensitive parts of macOS. Apart from its vulnerability, it’s encrypted, and until a user enters their password, when FileVault is enabled, macOS has no access to its contents. As these patches are associated with a specific System volume, they need to be stored on a volume in the same boot volume group. This could either be achieved using a dedicated volume, or an existing one, such as the Preboot volume which already contains iBoot. Either way, it’s likely to be encrypted by the system and sealed to ensure the integrity of the patches.

The most likely means to deliver these patches is Software Update, but they won’t come as traditional Installer packages. Instead a more secure mechanism not unlike current macOS updates is more likely, which will decompress and install the patches, and perform whatever magic is necessary to apply them.

It’s possible that Apple’s kernel engineers have devised a method to live patch the running kernel. In kpatch, Red Hat has been doing this for Linux distros over the last eight years, and Linux has alternatives such as Ksplice and KernelCare, and kexec which can boot a new kernel from that currently running. That said, it would appear to be very challenging to integrate live kernel patching into the Secure Boot process. Thus it may be that RSR can’t be used to patch the kernel.

Another obstacle to be overcome when patching is the Boot Kernel Collection, compiled from all the standard kernel extensions which have to be loaded. As with the kernel, this is a fiddly part of the Secure Boot process, and may not prove amenable to live patching.

There’s a great deal more to the System volume than the kernel and its extensions, though, which should come well within the scope of RSR. The hope is that Apple will be able to distribute minor updates, such as that from 13.1 to 13.2, using its existing mechanism, and to accomplish most if not all of the patch updates, from 13.1 to 13.1.1 for example, using much smaller downloads and briefer installations. For those of us who survived the succession of large and slow updates to Big Sur, this will be a great step forward. Whether it will be possible for Monterey’s future security updates, only Apple knows.