Exclaves: Isolation, Recovery, and Security

• Exclaves are defined as isolated regions—physical, logical, or computational—that enforce exclusion and controlled recovery in system architectures.
• In network percolation, exclaves enable the reclamation of isolated clusters, increasing the giant component size and overall system resilience.
• In hardware and OS security, exclaves isolate tasks to provide modular attestation, mitigate kernel compromise risks, and reduce the trusted computing base.

An exclave is a systemically isolated region—physical, logical, or computational—whose boundaries and internal structural modalities are defined so as to enforce exclusion from an adjacent environment. The concept finds rigorous instantiation across domains including percolation theory (network science), federated learning platform security, and modern operating system kernel architectures. In all manifestations, exclaves serve as a mechanism for structural isolation, controlled integration, and targeted recovery or auditing, in contrast to either wholly isolated or unrestricted regions.

1. Exclaves in No-Exclaves Percolation and Network Theory

In no-exclaves percolation (NExP), exclaves denote clusters of unoccupied @@@@1@@@@ entirely surrounded by occupied nodes within a network. The principal distinction from classical percolation is that, in NExP, when an exclave is detected—meaning all links from the unoccupied component connect exclusively to occupied nodes (excluding the largest unoccupied component)—it is "reclaimed" by merging with the adjacent occupied clusters. Exclaves are thereby prohibited from remaining isolated, resulting in a nonlocal percolation process that fundamentally alters network connectivity profiles (Min et al., 6 Feb 2024).

The determination of system robustness is reframed: the size of the largest connected component (the “giant NExP component”) now incorporates these “virtually” recovered exclaves. This mechanism induces discontinuous transitions, multiple distinct connectivity regimes, and enhanced system resilience compared to classical models.

2. Theoretical Frameworks and Formalization

In NExP on random networks, a mean-field solution employing generating function formalism achieves a tractable representation of exclave dynamics. Nodes have a degree distribution $P(k)$, with associated generating functions:

$$G_0(x) = \sum_{k=0}^{\infty} P(k)\,x^k,\qquad G_1(x) = \sum_{k=1}^{\infty} \frac{kP(k)}{z}\,x^{k-1},\qquad z=\langle k\rangle$$

The self-consistency equations partition the treatment of occupied, unoccupied, and merged clusters. For unoccupied clusters:

$w = q + (1-q) G_1(w)$

For NExP clusters, the recursive structure is:

$$F_1(x) = q\,x\,G_1(1-w+F_1(x)) + (1-q)\,x\,G_1(F_1(x))$$

$$F_0(x) = q\,x\,G_0(1-w+F_1(x)) + (1-q)\,x\,G_0(F_1(x))$$

A further self-consistency variable $u = F_1(1)$ is used. The giant NExP component’s size $\Phi$ is given by:

$$\Phi = 1 - q\,G_0(1-w+u) - (1-q)[1 - G_0(w) + G_0(u)]$$

Such quantification allows explicit calculation of phase thresholds and reveals the emergence and disappearance of exclave-mediated connectivity.

3. Exclaves in Hardware Security and Federated Learning

In security architectures, particularly within federated learning platforms (FL), exclaves represent hardware-isolated execution contexts focused on integrity rather than confidentiality (Guo et al., 13 Dec 2024). ExclaveFL assigns each federated task (local training, aggregation, differential privacy mechanisms) to its own exclave, typically implemented as a VM with integrity-only guarantees.

This design contrasts with TEEs (trusted execution environments): exclaves do not store secret key material in memory, emphasizing control flow and memory integrity. Each task’s execution produces a signed hardware attestation report, containing measurements of code, inputs, and outputs. These reports are aggregated into a universally verifiable, append-only transparency ledger.

An Attested Dataflow Graph (ADG) is built from the collection of exclave executions:

• Vertices denote individual exclave executions, each specified by input set, code measurement, output set.
• Edges represent intersecting data flows: $$e = \{(v_1,v_2) \mid v_1.in \cap v_2.out \neq \emptyset\}$$, labeled by $l(v_1,v_2) = v_1.in \cap v_2.out$.
• The ADG, $(V,E,l)$, encodes the provenance of computation.

The system achieves less than 9% runtime overhead in practical compute-intensive FL workloads and enables robust detection of protocol deviations, data poisoning, or task reordering.

4. Kernel Isolation and System Security (Modern iOS Exclaves)

In Apple’s iOS kernel architecture, exclaves are “access-scoped” groupings of resources isolated from the main XNU kernel and reside across guarded trust domains, as governed by the Secure Page Table Monitor (SPTM) (Steffin et al., 10 Oct 2025). Sensitive operations—sensor services, code signing, segments of the Neural Engine—are moved into Exclaves, which run at different guarded levels (GL). The Secure Kernel (SK), operating at GL1, is invoked via SPTM and registers resources and dispatches service requests.

Exclaves' code and data reside in dedicated, SPTM-retyped memory frames (e.g., SK_DEFAULT, SK_IO) that cannot be arbitrarily accessed or written by the XNU kernel. SPTM validates allowed transitions:

$$(0x4fffffd1c0fe177e >> (frame\_sptm\_type$$

This prevents unauthorized mapping and strictly enforces memory access policies.

Communication between XNU and Exclaves uses:

• xnuproxy: secure request handler forwarding downcalls and upcalls, integrating shared IPC buffers for parameter exchange.
• Tightbeam IPC: a type-checked inter-process communication framework, allocating IPC buffers (tb_transport_message_buffer_t), encoding message state/disposition, and activating endpoint objects with functions like tb_endpoint_create_with_value.

These mechanisms tightly regulate access, protect from kernel compromise, and support a more microkernel-like system structure.

5. Phases, Transitions, and Implications for Robustness

Exclaves in percolation models yield multi-phase transitions:

Occupation Probability	Giant NExP Component	Giant Unoccupied Component
$q < q_c$	Absent	Present
$q_c < q < q^*$	Present	Present
$q > q^*$	Present	Absent

Thresholds are explicitly computable; e.g., for random networks, $$q^* = 1-\frac{\langle k\rangle}{\langle k^2 \rangle - \langle k\rangle}$$.

In real-world networks—Internet AS-level, airport graphs—NExP theory and simulation demonstrate: (1) excellent alignment with predictions; (2) the recovery rule for exclaves produces a higher giant component size and system resilience compared to classical models. A plausible implication is that systems supporting exclave recovery attenuate catastrophic fragmentation and benefit from inherent self-healing properties.

Similarly, in federated learning and OS security, exclaves materially reduce the trusted computing base, enforce modular attestation, and lessen the impact of compromise or deviation. This layered compartmentalization is now a foundational mechanism in modern secure architectures.

6. Comparative Analysis and Domain-Specific Evolution

Past architectures (classical percolation, TEEs, monolithic kernels) revealed limitations in isolation, transparency, and resilience. Exclaves introduce:

• Proactive merging of isolated regions (NExP percolation), generating nontrivial transitions and enhanced network connectivity.
• Fine-grained hardware attestation and modular provenance (ExclaveFL), resolving vulnerabilities in confidentiality-dependent TEEs.
• Segregation of trusted functionality into rigorously enforced domains (iOS Exclaves), reducing systemwide risk in case of kernel compromise.

This suggests exclaves serve as an organizing principle for expressing and managing trust boundaries, with applications traversing network science, computational security, and system design. Their continued evolution is likely to affect future strategies for compartmentalization and recovery in distributed, secure, or resilient architectures.