Exclaves: execution, resources, and security boundaries
Security index · SPTM/TXM/Exclaves entry map
Under CONFIG_EXCLAVES, XNU coordinates work with the secure kernel and Exclaves services. It implements the userspace control trap, task associations, resource names and ports, RPC/upcall loops, host scheduling responses, VM-page donation, shared mappings, and bridges into VFS and IOKit. The secure kernel, Exclaves services, XrtHosted provider and parts of the transport are built elsewhere. The available source is rich enough to trace XNU's side of these interactions, including failure and return paths.
Detailed reading route
| Guide | What it traces |
|---|---|
| Execution, scheduler, and upcalls | Trap authorization, per-thread IPC context/SCID, proxy protocol, per-core request/response buffers, sk_enter, epoch waits/wakes, upcall dispatch, interrupt resumption and cleanup |
| Resources and physical memory | Resource-domain tables and send rights; task/conclave state machine; page donation and return; service permissions, SPTM frame types, device-pager mappings and copy bounds |
| Services and diagnostics | Storage to VFS, sensor/arbitrated-buffer operations, driver upcalls, Mach/kqueue notifications, always-on work and inspection/panic contexts |
A conclave in this code is a resource associated with an XNU task and an external manager/control connection. Its local lifecycle is represented by conclave_resource_t; the task has an association with that resource. It is not itself the thread's IPC context or scheduling-context ID. conclave_resource_t, task attachment.
One endpoint call crosses several layers
Mermaid source
sequenceDiagram
participant U as XNU userspace
participant T as Exclaves control trap
participant P as Proxy RPC loop
participant H as Hosted scheduler / sk_enter
participant S as Secure kernel and service
participant C as XNU upcall handler
U->>T: Operation, service ID and IPC buffer
T->>T: Authorization, size and service-membership checks
T->>P: Per-thread IPC context
P->>H: Resume scheduling context
H->>S: Enter external secure implementation
S-->>H: Return scheduler response
H-->>P: Resume/proxy progress
P->>C: Dispatch UPCALL when requested
C-->>P: Typed completion
P->>H: Resume to deliver upcall result
H->>S: Continue service
S-->>H: Eventual reply through scheduler path
H-->>P: RPC reply available
P-->>T: Completed call
T-->>U: Buffer copyout and result
Scheduler responses and RPC responses are distinct protocols. A scheduler wait can block an XNU thread and later resume the same secure context; an RPC UPCALL asks XNU to perform a particular service operation; an interrupt can temporarily enter XNU without completing either protocol. Follow the execution guide for the precise loops and state flags. The diagram omits failure and repeated scheduling steps.
The objects are not interchangeable
| Object or identifier | Role |
|---|---|
| XNU task and attached conclave | Process lifecycle and resource-domain association |
exclaves_resource_t and Mach port |
Named/typed resource, active-use state and local capability lifetime |
| Thread IPC context and SCID | A communication buffer and external scheduling-context identity |
| Per-core hosted scheduler buffers | Request/response transport storage that requires CPU/interrupt discipline |
| Secure shared-memory handle | Service-issued mapping identity |
| Physical frame type | Monitor-level classification checked during donation, mapping and return |
Definitions and implementation: resources, thread fields, scheduler buffers, shared-memory handle, frame validation.
For example, endpoint calls in this snapshot use an authorized service ID and require MACH_PORT_NULL in the port argument. Buffer and sensor operations instead resolve resource send rights. A valid buffer port does not turn its numerical name into an endpoint ID. Shared physical pages then require service-level mapping permission and a suitable SPTM shared-frame type before XNU creates PTEs. Control trap, resource-port resolution, mapping trace.
Scope of the expanded reading
The detailed guides trace startup dependencies, trap and kernel downcalls, proxy/scheduler loops, memory/resource lifetimes, task state transitions, representative services, and interrupted-domain return. The secure-side implementations, complete generated transport, all provider policy and every timing combination remain outside this checkout's evidence. Runtime tests were not run.
Use SPTM for typed-memory and protected-call boundaries, TXM for execution-policy requests, Mach IPC for resource-port rights and notification delivery, and ARM64 exception return for the ordinary XNU machinery surrounding protected-domain resumption.