Exclaves, XNU and the future.

[Jimmyjames]

Continuing my series of very niche interests, I was recently considering if anything significant has changed with regard to XNU.

For anyone who doesn’t know, XNU is the name of the kernel in pretty much all of Apple’s products. It’s comprised of the Mach microkernel and quite a bit of FreeBSD’s code. Unlike Mach, XNU isn’t run as a microkernel, but as a more traditional monolithic kernel with loadable kernel modules. Pretty much the standard for mainstream os’s these days. That has its good points and bad points. They are too numerous to go into here, and indeed, my neophyte understanding may be unaware of them, but essentially I would say the current situation gives pretty good performance, all essential low level services are within the kernel, bypassing the need for slower message passing that early iterations of Mach incurred. The main downsides are complexity: the kernel is a very thorny place to venture into, and any small error can wreak havoc. Secondly there is the issue of security. That is, once you are in the kernel, you can pretty much do anything. This can lead to big security and stability problems.

Over time, Apple has locked down kernel access even on macOS to developers. Kexts are increasing difficult or impossible to use. Drivers must be developed in userland using various frameworks Apple has developed. Even useful utilities like Dtrace (an instrumentation and debugging tool) have been restricted. I began to wonder if this restriction was in service of something more ambitious. Not just control, but the ability to slowly migrate from XNU to something more secure, efficient and stable.

There were rumours about an academic project called L4, a very efficient and small microkernel. Indeed, the Secure Enclave uses L4 at its heart. Nothing seemed to happen for while though.

As luck would have it, I also recently saw an article https://www.df-f.com/blog/ios17 which goes into some new features of iOS 17. These are low level features for Apple themself, rather than devs. They are designed primarily to increase security. One thing stood out in the article however:

This is in line with the few mentions of "exclaves" spotted elsewhere in strings. It seems Apple's new design is to transition away from the PPL to this new, micro-kernel like architecture, in which XNU's security functionality is refactored and isolated into exclave domains. Those are kept physically separate from XNU proper, so that even a hypothetical kernel compromise would be unable to further jeopardize the integrity of the other exclave components.

Very interesting! Could this be a new direction? These “exclave domains” which allow partial compromise of a kernel without all parts being effected. It’s an intriguing and exciting idea to me. Could they spread to other kernel areas?

I’d be interested in any thoughts anyone might have on this, even though I do realise this is not a mainstream area of interest.

 

[Cmaier]

Could be. Very typical of Apple to make these low-level advancements without anyone noticing

 

[Yoused]

I have been reading about microkernels for many years. L4 was started about a quarter century ago and evolved into a stable version called seL4 that gets used for stuff. Unlike Mach, L4 just hands messages between domains without examining them, and leaves it to the recipient to decide if it is within privilege bounds. Also, L4 leaves page table management and swapping and many other kernel-level functions to userland processes, where they are less likely to cause kernel panics/system failure. This places seL4 on the edge between microkernel and exokernel (a design where privileged code is at the absolute minimum). The GNU OS project is trying to create this kind of modular system but are using GNUMach instead of L4 due to porting difficulties.

 

[Nycturne]

Over time, Apple has locked down kernel access even on macOS to developers. Kexts are increasing difficult or impossible to use. Drivers must be developed in userland using various frameworks Apple has developed. Even useful utilities like Dtrace (an instrumentation and debugging tool) have been restricted. I began to wonder if this restriction was in service of something more ambitious. Not just control, but the ability to slowly migrate from XNU to something more secure, efficient and stable.

The driver situation isn't terribly surprising, as I don't think the idea of kicking drivers into userland is a new one. It's just been with the more recent security environment a more urgent issue. Windows is even pushing drivers into user space, just a little less forcefully than Apple (as they tend to do with all transitions).

I would be surprised if they fully migrated away from XNU, but we could see changes large enough that the architecture would be a shock to anyone who's been asleep for the last 10-15 years.

Very interesting! Could this be a new direction? These “exclave domains” which allow partial compromise of a kernel without all parts being effected. It’s an intriguing and exciting idea to me. Could they spread to other kernel areas?

Certainly looks that way. Interesting that PPL was only introduced in A12 and already being retired in favor of this new GXF model. But I think the interesting bit is that some of the first components moved into exclaves are things that allow XNU to be effectively "demoted" in some ways. It's isolating core pieces of the security model away from the kernel, which seems to be a good place to start.

 

[Yoused]

The driver situation isn't terribly surprising, as I don't think the idea of kicking drivers into userland is a new one.

There used to be a reason for having drivers in privileged space. They often handled the hardware aspects of device communication, or critical timing-related protocols. There is enough standardization these days that drivers really only handle high-level communication, such as can be done in userland, with no impact on performance. If you design hardware that uses unique protocols that must be done at the supervisory level, I should expect it would be a specialized thing requiring special support from the OS vendor, not a broadly accessible consumer-level product.