I suspect it's something like "apply the changes to the SSV in the background, and meanwhile apply the mitigations to the running system" - and after a reboot they're in place.
Right. The OS is a read-only volume, but that's only for when it's being read off the disk into system memory. No reason a patch could not be loaded into both disk (SSV requiring reboot) and RAM (actively loaded) simultaneously. The kernel would need to approve, but if the kernel approved it could change any memory address it wants.
In theory, a Rapid Security Response is not necessarily only an update. It's a Response. It could contain instructions saying, hey, update this file here, and then patch in memory these particular address to specific new values.
I did a ⌘F of “cryptex” and didn’t find anything so I feel like the author might’ve missed that Apple pulled the shared cache out of the normal SSV and loads it separately, which might make it easier to update. On iOS there’s a separate cryptex containing just WebKit and associated frameworks so it seems pretty clear that this is to be the mechanism for rapid security updates, especially if you’ve been listening in to what the team has been talking about during WWDC. But you’d have to know the right people and questions to ask for that ;)
@never_released is exactly where I ended up, but I was hoping there was more information available. Sadly, it looks like researchers on Twitter and `man cryptex` are the only sources of information floating around for this stuff.
Apple will probably write a paragraph in the platform security guide this fall. The real meat of it will probably remain on Twitter, or if you're lucky, a good blog post.
Most likely the patches will require digital signatures by Apple and the kernel will verify the signatures before allowing itself to be patched. Most likely the signatures will be compiled into the kernel itself and not be part of any external configuration file. Not a great vector.
