Central to the secure design of Apple silicon is Secure Boot, the intricate mechanism that ensures everything in the boot process from firmware through to macOS and its extensions is verifiably secure. Full Security is the default and standard level set by Apple, although you can choose to run at Reduced Security in order to load user-approved kernel extensions. As Apple has officially deprecated those kernel extensions in favour of system extensions, which are intended to function fully in Full Security, very few Apple silicon Macs should now need to run at anything other than Full Security. That’s the theory, but does it work in practice?

While most software that has previously relied on kernel extensions has been able to replace them with system extensions and their kindred that work in Full Security, there are some important exceptions. Here I’ll consider two: SoftRAID and Rogue Amoeba’s Audio Capture Engine, ACE.

SoftRAID is a popular and superior alternative to the software RAID implementation offered through Disk Utility. Despite what I must presume were prolonged efforts to turn it into some form of system extension that could be loaded without changing security level, Apple has finally included its kernel extension in Ventura 13.3. Now that it’s part of the standard macOS system software, it’s included in the Boot Kernel Collection and no longer requires the user to adopt Reduced Security and enable its loading. While that’s good news, it’s also an admission that SoftRAID couldn’t be implemented without using a kernel extension after all. It hasn’t been explained why it has taken over two years to solve this.

Rogue Amoeba’s audio tools are justly popular, and its developers have been able to deliver the features of its Audio Capture Engine using a system extension instead of the previous kernel extension. However, for the moment at least, in order to install and use that system extension, Apple silicon Macs require the adoption of Reduced Security, just as if it was still a kernel extension. No explanation has been given as to why that should be so, and Rogue Amoeba is adamant that ACE doesn’t interact directly with the kernel in any way.

These are two admittedly challenging problems in the transition from kernel extensions: in one, it appears that the code must continue to run as a kernel extension, so it has to be made part of macOS; in the other, despite becoming a system extension it still requires a change in security level to be able to use it, which shouldn’t have been necessary.

SoftRAID demonstrates that, no matter how Apple might want us all to believe that there’s no need for third-party kernel extensions, there are occasions when there’s no other option. Yet Apple insists that support for kernel extensions is going to be removed. In its Platform Security Guide, for example: “This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon.” Again in Developer Support: “As part of our ongoing effort to modernize the platform, improve security and reliability, and enable more user-friendly distribution methods, kernel extensions have been deprecated.”

Rogue Amoeba’s ACE demonstrates that even when you do follow Apple’s instructions for developing a system extension, it can still require Reduced Security. But does that really matter, or is Apple gilding the lily in Full Security? Apple describes Reduced Security as permitting “actions that can put a user’s system security at risk”, pointing out that “kexts have the same privileges as the kernel, and thus any vulnerabilities in third-party kexts can lead to full operating system compromise.” And that’s Apple’s justification for developers to switch to system extensions. Nowhere can I find an explanation from Apple as to why a system extension should require Reduced Security.

The current version of Apple’s Platform Security Guide is dated May 2022, and its annual update is well overdue. I’m looking forward to reading explanations for these contradictions in the current implementation of Secure Boot.

I’m very grateful to Ron for reminding me of these discrepancies, in his comment to my article on deprecation.