The Secure Enclave processor (SEP) is a separate processor that holds cryptographic material unique to the chip. That material is isolated from whatever compromise might happen on the main application processor; and there is no particular reason why you need more than one of them, even for multi-user. macOS has multiple users and uses the Secure Enclave just fine. For data encryption you'd have the SEP derive a different key for each user.

Secure Exclaves are special isolated processes that run on the same application processor as the regular OS. They're a very new OS feature and AFAIK Apple has barely talked about them until now.

Exclaves are isolated because Apple made a proprietary CPU extension called Guarded Exception Levels. It lets you separate an ARM exception level out into two privilege levels: guarded and unguarded. The guarded level can have different page permissions from the unguarded level, and switching between the two modes is extremely fast. Apple uses this to lock down iOS: its kernel, XNU, has it's entire virtual memory system hollowed out and replaced with a thing called the Secure Page Table Monitor (SPTM). XNU lives in EL2 (ARM hypervisor) but SPTM lives in GL2 (guarded hypervisor). In this configuration, SPTM is the only thing that can allocate memory, and it controls all memory allocations in the system. This is specifically why jailbreaks have become far harder to make[0]: you basically need to hack SPTM to get anything.

XNU, strangely enough, lives in both EL2 and EL1 (ARM kernel); but Apple also uses GL1 (guarded kernel) for a second, funnier OS called the Secure Kernel (SK). SK has its own exclusive resources and userland. Processes that run under SK cannot be tampered with or monitored by XNU because SPTM isolates them and their kernel from XNU. This is used for isolating any particularly security sensitive thing.

For example, code signing enforcement happens in an Exclave[1]. XNU can't run unsigned processes because it needs SPTM to bless the pages. But SPTM is supposed to be a very small attack surface; there is a long history of using memory safety bugs in the verification code to gain higher levels of privilege, so putting that code in GL2 would be bad. Instead, it gets put in an Exclave, where:

- A compromised XNU cannot tamper with the verifier, because SPTM won't give it write access to the pages.

- A compromised verifier doesn't compromise the whole system, because it's not part of SPTM/GL2.

- A compromised verifier can't interfere with other exclaves, because they're isolated by SK.

The only thing a compromised verifier can do is fail to reject an unsigned program, which would let you run specific unsigned code in EL0. You would not suddenly get kernel mode access from a verifier failure.

Anyway, what makes this relevant for HomeView is that all the microphone data processing can be isolated in an Exclave from the rest of the OS. So if the CIA wants to force your HomeView to listen to you, it needs to either compromise SPTM (very hard), or find a (non-memory-related) logic error in the listener exclave.

[0] This is also morally the same scheme as the Xbox 360 hypervisor that went decades without a softmod

[1] Morally speaking, it's an Exclave; it lives in GL0. But technically the code signing enforcement is in a different SPTM domain from the Secure Kernel, called the "Trusted Execution Monitor" (TXM). I would not be surprised if Apple migrates it over to an Exclave in the future.

Apple HomeView