A short history of Mac OS extensions

One of the first things that we did with early personal computers was to personalise them further by extending their operating systems. For PCs, that came in software devices such as ‘terminate and stay resident’ (TSR) programs, and for Classic Macs in different types of extension to the System. In those days, executable code was contained in resources attached to files. The resource type used for extensions was named INIT, so an alternative name for these extensions was INITs. Later, some were included in Control Panels, giving the user an easy way to configure their appearance and behaviour.

Rise

Because these INITs patched the System, they brought with them the risk of instability, and of conflicts with other extensions. Those could easily get out of hand, so in System 7.5 of 1994, Apple introduced the Extensions Manager, to make it easier to enable and disable individual extensions. The previous year, Casady & Greene had introduced Jeffrey Robbin’s invaluable Conflict Catcher which quickly became very popular.

The number of extensions involved was often great: here, although my Mac had only one Early Startup File, it had 50 other Startup Files whose loading order could be rearranged to improve stability, a further 121 other extensions, and 23 Control Panels. Even with the aid of Conflict Catcher, managing all those became a nightmare.

Kexts

Mac OS X did away with all those, replacing them with a different architecture where a relatively small kernel had scores of kernel extensions (kexts) to support different types of storage, networking, and pretty well everything else our Macs could do. It wasn’t long before kexts went the same way of Classic extensions, only this time there was no Conflict Catcher to help.

Here’s a small sample of those I used in about Mac OS X 10.4 Tiger in 2005.

In early Mac OS X, kexts were loaded individually after the kernel. As that took increasing time, Mac OS X took to prebuilding kexts into caches that could be loaded more rapidly following booting of the kernel. Almost every hardware device came with its own kext(s), and they were also popular even among fairly mundane apps.

Not only were there many kext conflicts, and plenty of old and outdated kexts causing havoc, but some proved impossible to load in the first place, here in Mac OS X 10.6 Snow Leopard. A few even appeared to be malicious.

XProtect

To try to address this, Apple introduced blacklists of known bad kexts, that the system blocked using XProtect. These were extended in El Capitan (OS X 10.11, 2015) to block a long list of incompatible kernel extensions (KEXTs), and a shorter list of undesirable Safari extensions.

The list of blocked kernel extensions was split between Incompatible Kernel Extension Configuration Data, kept in /System/Library/Extensions/AppleKextExcludeList.kext, and XProtectPlistConfigData. The former data was seldom updated, but XProtectPlistConfigData changed more frequently. The scale of the problem was such that, in 2015, XProtect’s configuration files listed more than 10,000 signed kernel extensions that were permitted to load in OS X.

Kernel extensions are vital – they include all the main hardware drivers to make your Mac work – but because they operate so close to the kernel, they have become an Achilles heel. Even simple conflicts can make a Mac unusable, and a malicious kernel extension would be catastrophic. Patrick Wardle of Objective-See introduced KextViewr to inspect extensions, and check that they’re all above board.

EtreCheck is another long-established utility that examines kexts that are currently installed.

Decline

Around the time of El Capitan and Sierra, Apple started to make discouraging noises over the future of kexts in macOS. While they remained an essential part of the system architecture, like the kernel kexts run at the highest level of privilege, so allowing kexts to be written by third-parties opened macOS to the risks of malicious or simply buggy kexts causing kernel panics and havoc. With the wisdom of hindsight, it’s obvious that this formed part of Apple’s plan for Secure Boot in Macs built around its own chips rather than Intel processors.

It makes all-round good sense to move as much code as possible from running with the same privileges as the kernel, to running at a user level. To enable that, Apple had to provide system support for alternatives such as what are now known as system extensions, provision for hardware drivers, network extensions, endpoint security, and file systems. In a few cases, such as the software RAID utility SoftRAID, Apple has been unable to achieve that; as a result SoftRAID’s kext is now bundled in macOS as standard.

This made even better sense with the arrival of macOS Big Sur and Apple silicon Macs, with their Secure Boot. Almost all system kexts are now stored on the Signed System Volume (SSV), which can’t contain third-party kexts. The kernel and system kexts are built into a Kernel Collection not unlike the kernel caches of the past.

When an Apple silicon Mac boots without any third-party kexts, it does so with full security. When it’s intended to use a third-party kext, a different Kernel Collection is required; as that doesn’t enjoy the same level of protection as the contents of the SSV, the user has to drop the Mac’s security policy to Reduced Security and explicitly enable the loading of third-party kexts.

Fall

Apple hasn’t yet announced when third-party kexts will go away altogether, but their days are certainly numbered.