Do M4 chips have a new security processor?

There was a stir of excitement last year when some claimed that Apple’s M4 and the A18 chip inside iPhone 16 models had a new security processor, the Secure Exclave Processor, a sister to the Secure Enclave Processor in all modern Macs. This article considers whether there’s evidence to support that.

Secure Enclave

The first Macs with a secure enclave and its processor, the SEP, were released over eight years ago, in the MacBook Pro 2016 models with a T1 chip. They were quickly succeeded by the iMac Pro at the end of 2017, with the T2 chip that became universal across the last models of Intel Macs. Inside each T2 chip is a 32-bit Arm core running sepOS to store and handle encryption keys and support other security features.

When Apple released the first M1 Macs, they too came with their own SEP, this time integrated into the main chip, but still running sepOS. Apple provides extensive details of each SEP used up to May 2024 in its Platform Security Guide.

During kernel boot of an M4 Pro running macOS Sequoia 15.3.1, the SEP writes a useful commentary of its startup to the Unified log. The SEP’s key store is started about 5 seconds after the initial system boot entry, and before the other CPU cores are started up. SEP boot takes place a little later, and it then starts handling messages. Support for biometric authentication follows, as does key unwrapping for apfs. Although the SEP isn’t loquacious, it is far from silent in the log.

Enclaves, exclaves, conclaves

To the best of my knowledge, the first description of exclaves in Apple’s operating systems was that of Dataflow Forensics on a beta-release of iOS 17 on 8 August 2023. They proposed that exclaves are code domains isolated from the kernel itself, so that, should the kernel become compromised in any way, components in exclaves should remain protected. I followed that with a report of new exclave kernel extensions in macOS 14.4, discussed here, and referenced back to Apple’s XNU source code.

It’s useful to distinguish between these three terms in their normal usage:

an enclave is a territory entirely surrounded by the territory of another state;
an exclave is an isolated fragment of a state that exists separately from the main part of that state;
a conclave is a private meeting or close assembly, more specifically a meeting of the College of Cardinals convened to elect a new Pope.

Based on those and XNU sources, I proposed last August that exclaves provide a static set of resources to the XNU kernel. Examples include conclave managers, services like Apple ID for VMs, named buffers and audio buffers. These resources are named and have a corresponding identifier shared between XNU and the enclave. Those are discovered during the boot process, and made available in a table at two levels: a root table assembles resources by their scope, while secondary tables list actual processes.

For example, a root table entry for the domain com.apple.conclave.a might link to a secondary table listing an audio buffer, an audio service as a conclave manager, and additional buffering. In the case of audio exclaves, they might be used to connect a system extension running with user privileges to privileged access in the kernel and its extensions.

Support in Sequoia

As of Sequoia 15.3.1, there are three kernel extensions supporting exclaves:

ExclaveKextClient.kext 1.0.0
ExclaveSEPManagerProxy.kext 1.0
ExclavesAudioKext.kext 220.24

There are also two private frameworks:

CoreSpeechExclave.framework 1.0 (3403.7.3)
libmalloc_exclaves_introspector.framework 1.0 (1)

There’s a group of private entitlements governing access to exclave and conclave functions, whose names start with com.apple.private.exclaves.

There are also multiple references to Tightbeam, which doesn’t appear to have been released in open source. This refers to highly focussed lasers used in communications in The Expanse sci-fi. In macOS, it first appeared as the name of a Private Framework released in macOS 13.0, and supported since then.

Examination of the 15.3.1 kernel boot sequence in the log reveals a single entry relating to exclaves, in which the neural engine (ANE) states that no exclaves are assigned to it, as it boots, far later in the sequence than SEP activity:
ANE0: start: No Exclaves assigned to ANE

XNU source code based on macOS Sequoia 15.0 reveals that code in exclaves is either run in CPU cores, for which there is code to support the management of multiple cores, or in the neural engine (ANE).

Summary

The Secure Enclave is an isolated processing unit within Apple silicon chips that stores and handles encryption keys and supports other security features. It runs its own operating system, sepOS.
Exclaves are managed code resources that are run in isolation from the kernel, and are currently used for I/O to support audio and CoreSpeech, sensors, and possibly for Apple ID for VMs. They run in CPU cores and the neural engine, and although they may have privileged access to hardware, they have no processor of their own, in Macs at least.
Conclaves are close assemblies of exclaves, and should never communicate by fumata.

I’m grateful to Ben for rekindling my interest.