Modern iOS Security Features -- A Deep Dive into SPTM, TXM, and Exclaves (2510.09272v1)
Abstract: The XNU kernel is the basis of Apple's operating systems. Although labeled as a hybrid kernel, it is found to generally operate in a monolithic manner by defining a single privileged trust zone in which all system functionality resides. This has security implications, as a kernel compromise has immediate and significant effects on the entire system. Over the past few years, Apple has taken steps towards a more compartmentalized kernel architecture and a more microkernel-like design. To date, there has been no scientific discussion of SPTM and related security mechanisms. Therefore, the understanding of the system and the underlying security mechanisms is minimal. In this paper, we provide a comprehensive analysis of new security mechanisms and their interplay, and create the first conclusive writeup considering all current mitigations. SPTM acts as the sole authority regarding memory retyping. Our analysis reveals that, through SPTM domains based on frame retyping and memory mapping rule sets, SPTM introduces domains of trust into the system, effectively gapping different functionalities from one another. Gapped functionality includes the TXM, responsible for code signing and entitlement verification. We further demonstrate how this introduction lays the groundwork for the most recent security feature of Exclaves, and conduct an in-depth analysis of its communication mechanisms. We discover multifold ways of communication, most notably xnuproxy as a secure world request handler, and the Tightbeam IPC framework. The architecture changes are found to increase system security, with key and sensitive components being moved out of XNU's direct reach. This also provides additional security guarantees in the event of a kernel compromise, which is no longer an immediate threat at the highest trust level.
Summary
- The paper presents a reverse engineering analysis showing that SPTM serves as a root of trust for memory management amid shifting privilege domains.
- It details how TXM and Exclaves, operating in isolated domains, enhance security by enforcing strict memory retyping and controlled communication.
- The methodology combines static and dynamic analysis to validate the microkernel-inspired architecture, reducing the attack surface for kernel exploits.
Architectural Evolution of iOS Security: SPTM, TXM, and Exclaves
Introduction
This paper presents a comprehensive reverse engineering analysis of the latest iOS security architecture, focusing on the Secure Page Table Monitor (SPTM), Trusted Execution Monitor (TXM), and Exclaves. The work systematically dissects the transition from a monolithic kernel model to a compartmentalized, microkernel-inspired architecture, emphasizing the introduction of new privilege domains, memory isolation mechanisms, and secure inter-component communication. The analysis is grounded in static and dynamic reverse engineering of recent Apple hardware and firmware, with particular attention to undocumented Apple-proprietary extensions to the ARMv8-A architecture.
System Architecture and Privilege Separation
The iOS kernel (XNU) historically operated as a monolithic entity, with all system services residing in a single privileged address space. This design exposed the system to catastrophic compromise in the event of a kernel vulnerability. The paper details Apple's recent architectural shift, introducing horizontal Guarded Levels (GLs) via the Guarded Execution Feature (GXF), in addition to the standard ARM Exception Levels (ELs).
Figure 1: Exception levels on AArch64 with the common usage model applied, showing the vertical privilege hierarchy.
The GXF introduces lateral privilege domains (GL0, GL1, GL2), each with distinct access and execution permissions enforced by the Shadow Permissions Remapping Register (SPRR). SPTM operates at GL2, the highest observed privilege, acting as the root of trust for memory management and domain separation.
Figure 3: System overview highlighting communication paths between XNU, SPTM, TXM, SK, and Exclaves across ELs and GLs.
Secure Page Table Monitor (SPTM)
Design and Initialization
SPTM is the central authority for memory frame retyping and page table manipulation. It is entered from XNU via the GENTER instruction, which transitions execution from EL2 to GL2. SPTM's initialization involves configuring GXF entry points and exception vectors, setting up SPRR permissions, and registering dispatch tables for each domain.
Dispatching and Domain Enforcement
SPTM employs a multi-level dispatch structure, with calls parameterized by a 64-bit sptm_dispatch_target_t encoding the target domain, dispatch table ID, and endpoint ID.
Figure 5: sptm_dispatch_target_t structure, showing domain, table, and endpoint encoding.
Dispatch tables are registered for each domain (XNU, TXM, SK, HIB), with strict permission bits controlling cross-domain invocation. The internal state machine of SPTM enforces allowed transitions and validates all requests against a transition table indexed by event and current state.
Figure 7: SPTM-internal state graph, illustrating domain-specific transitions and event-driven state changes.
Memory Retyping and Mapping
SPTM tracks physical memory frames in a global frame table, with each frame assigned a type corresponding to its owning domain. Retyping is strictly controlled: only the owning domain can retype its frames, and allowed transitions are encoded in a global bitmask table.
Figure 2: Early validation in SPTM retype, ensuring address bounds and type constraints.
Page table updates are exclusively performed by SPTM. XNU requests mappings via sptm_map_page, but is only permitted to map to a restricted subset of frame types (e.g., XNU_DEFAULT, SK_SHARED_RW/RO). SPTM enforces both the type of the target frame and the type of the page table being modified, preventing XNU from mapping into privileged or cross-domain memory.
Figure 10: Schematic of XNU invoking sptm_map_page to request a new mapping, with SPTM enforcing type and domain constraints.
Security Implications
This architecture ensures that even a fully compromised XNU kernel cannot arbitrarily modify page tables or access memory belonging to other domains (e.g., TXM, SK, Exclaves). The attack surface for privilege escalation is thus significantly reduced, and the system can enforce least-privilege separation for sensitive components.
Secure Kernel (SK) and Exclaves
SK as a Microkernel
The Secure Kernel (SK) operates at GL1 and acts as a microkernel for Exclave components. It registers its own dispatch tables with SPTM and manages memory retyping for SK-owned frames. SK exposes a function dispatch table to its GL0 clients (Exclavecore binaries), allowing them to request frame retyping and other privileged operations.
Figure 12: SK SVC #0 handling, where a user-provided pointer indexes a function table for dispatch.
SK also mediates calls from XNU into Exclaves, acting as a gatekeeper and scheduler for secure world execution.
Exclaves: Isolated Resource Domains
Exclaves are groupings of sensitive resources (e.g., sensors, audio buffers, ANE services) isolated in the SK_DOMAIN. Each Exclave resource is statically enumerated at boot and assigned to a domain, with access controlled by domain membership and entitlements.
Figure 4: Exclaves table structure, with a root table indexing domains and per-domain resource tables.
Conclaves, a subtype of Exclave resource, encapsulate services and maintain their own state machines and Tightbeam communication channels.
Figure 15: Conclave state machine, showing lifecycle transitions (attach, run, suspend, stop).
Communication Mechanisms
Exclaves support multiple communication mechanisms:
- Mach Ports: For resources like sensors and buffers, standard Mach IPC is used, with send rights granted only to entitled tasks.
- seL4-style IPC Buffers: For Conclave and service resources, communication occurs via per-thread IPC buffers, with scheduling context IDs managed by xnuproxy.
- Tightbeam: A secure IPC framework layered atop xnuproxy, providing structured message delivery and endpoint abstraction.
Figure 17: Exclaves user space call validation, enforcing entitlement and domain checks before invocation.
Real-World Security Impact
The migration of critical services (e.g., Secure Indicator Light) into Exclaves ensures that user privacy indicators cannot be subverted by compromising user-space daemons. The paper demonstrates that, unlike the legacy implementation, the new architecture prevents trivial circumvention of privacy indicators, as rendering is now managed in the secure world.
Trusted Execution Monitor (TXM)
TXM operates at GL0 in its own SPTM domain and is responsible for code signing and entitlement enforcement. XNU interacts with TXM via SPTM, passing requests through a dedicated dispatch table. TXM manages its own frame types and is protected from XNU by SPTM-enforced memory isolation.
Discussion and Implications
The introduction of SPTM, TXM, and Exclaves marks a significant architectural shift in iOS security. The system now enforces:
- Fine-grained privilege separation: Each sensitive component operates in its own domain, with SPTM as the sole authority for memory management.
- Strict memory isolation: Page table and frame type manipulations are only permitted by SPTM, with cross-domain operations tightly constrained.
- Secure IPC: Communication between domains is mediated by structured frameworks (Tightbeam, xnuproxy), with explicit validation of entitlements and resource ownership.
Strong claims in the paper include the assertion that a kernel compromise no longer implies full system compromise at the highest trust level, due to the enforced separation and mediation by SPTM.
Limitations include the lack of public documentation for many Apple-proprietary mechanisms, the evolving nature of the secure world ecosystem, and the incomplete reverse engineering of all GL0 Exclavecore components.
Future Directions
The paper identifies several open research questions:
- Full reverse engineering of Exclavecore GL0 binaries and their scheduling mechanisms.
- Detailed analysis of the seL4-inspired microkernel components in the secure world.
- Performance evaluation of the compartmentalized architecture versus the legacy monolithic model.
- Comprehensive threat modeling and formal verification of SPTM rule sets and state machines.
Conclusion
This work provides the first in-depth, systematic analysis of the modern iOS security architecture, revealing a transition towards a microkernel-inspired model with strong privilege separation, memory isolation, and secure inter-domain communication. The practical implications are substantial: sensitive services are now robustly isolated from the kernel, and the attack surface for privilege escalation is dramatically reduced. As Apple continues to evolve this architecture, further research will be required to fully characterize the security guarantees and performance trade-offs of this new model.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Overview
This paper takes a close look at how Apple has made iPhones and iPads more secure in recent years by reshaping how the “brain” of the operating system (called the kernel, named XNU) is built and protected. It focuses on three big features:
- SPTM (Secure Page Table Monitor)
- TXM (Trusted Execution Monitor)
- Exclaves (new “secure zones” inside the system)
Think of the kernel like a large control room. In the past, almost everything happened in that one room, so if a bad actor got in, they could do a lot of damage. Apple is now splitting this control room into smaller, locked rooms with different levels of access. The paper explains how these locks and rooms work together to keep the system safe, even if one part gets attacked.
What are the key questions?
The researchers wanted to understand, in simple terms:
- What exactly are SPTM, TXM, and Exclaves, and how do they protect the system?
- How do these parts talk to each other and to the main kernel?
- What rules do they follow to control access to memory (the place where programs keep data and instructions)?
- Do these changes actually make the system safer, and how?
- How do Exclaves communicate securely with the rest of the system?
How did they paper it?
The team mostly used “reverse engineering,” which means they carefully took apart the software to see how it works inside, like opening a device to paper its circuits. They:
- Examined different iOS versions and Apple chips (like iPhone 16 and iPad Pro with M4).
- Used special tools (like Ghidra) that are like digital microscopes for code.
- Read Apple’s partly open-source kernel code to match what they saw in practice.
- Tested on an Apple Security Research Device (SRD), which allows advanced debugging without jailbreaking.
Important terms explained simply
- Kernel: The operating system’s brain that controls everything.
- Monolithic vs. Microkernel:
- Monolithic = almost all services live in one big, powerful room.
- Microkernel-like = only essential services live in the powerful room; everything else lives in separate rooms with limited power.
- Memory pages and frames:
- Imagine memory like a big library. “Pages” are sections in the virtual address book, and “frames” are the shelves where data actually sits. Page tables are the map telling you which page points to which shelf.
- SPTM (Secure Page Table Monitor):
- The “head librarian” who controls how those maps (page tables) can be changed. It enforces strict rules so attackers can’t rewrite the maps even if they break into the kernel.
- GXF (Guarded Execution Feature) and Guarded Levels (GL):
- Think of GLs as VIP rooms next to the main floors of the building. Only specially authorized code can enter. SPTM runs in the highest VIP room (GL2).
- SPRR (Shadow Permission Remapping Register):
- A system of fast, flexible locks for memory. Instead of a simple “yes/no,” it uses a quick lookup to decide who can read, write, or run code in each memory area.
- TXM (Trusted Execution Monitor):
- A trusted clerk that checks code signatures and entitlements (like badges that say what an app is allowed to do).
- Exclaves:
- Strongly isolated mini-systems that run sensitive tasks away from the main kernel. They use secure messaging (like Tightbeam) to talk to the outside.
- IPC (Inter-Process Communication):
- Safe ways for different programs/rooms to send messages and requests to each other.
What did they find?
Here are the main results, described simply:
- SPTM sits at the highest guarded level (GL2), making it the most trusted part. It controls who can change the memory maps and enforces strict rules about what’s allowed.
- Apple added “guarded levels” (GXF) next to the normal privilege levels. This gives Apple more fine-grained control over who can do what, where, and when.
- Memory permissions are handled through SPRR, a flexible locking system that quickly decides access rights. This strongly protects page tables (the maps of memory), even if the kernel is compromised.
- SPTM introduces “trust domains” — separate zones with strict boundaries. Components in one domain can’t freely change memory in another. This limits the damage if something goes wrong.
- TXM runs at a lower guarded level and handles code signing and permission checks, but it must ask SPTM for certain operations.
- Exclaves build on these ideas: they strongly isolate sensitive code into tightly controlled spaces, and they communicate using secure channels (like Tightbeam and a handler called xnuproxy).
- The researchers mapped out how the kernel calls into SPTM (using a special instruction called GENTER), how TXM and the Secure Kernel talk to SPTM, and how Exclaves are integrated. They even did a first-of-its-kind experiment interacting with “conclaves” (Exclave parts) from user space.
Why this matters: by moving sensitive code out of the kernel’s direct reach, Apple reduces the impact of a kernel hack. A kernel compromise no longer automatically lets an attacker control everything at the highest level.
What’s the impact?
- Stronger security overall: Splitting the “control room” into protected mini-rooms (domains and Exclaves) means a single break-in doesn’t doom the whole system.
- Better defense against powerful attacks: Even if attackers gain kernel write access, they can’t easily rewrite memory maps or run code in the most sensitive areas.
- A step toward a more microkernel-like design: Apple still uses its own approach, but it’s moving toward smaller, safer components with clear boundaries.
- Real-world benefit: Users get more protection for things like code signing, sensitive data, and system integrity. Developers and security researchers get a clearer picture of how the system defends itself.
In short, Apple is building layered defenses inside iOS. SPTM, TXM, and Exclaves work together like locked rooms with vetted guards and secure messaging. This design makes iPhones and iPads harder to break in serious ways, even if one part of the system is attacked.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, focused list of unresolved issues the paper surfaces or acknowledges, phrased to guide follow-up research:
- Undocumented GXF register semantics: Precisely define GXF_CONFIG_ELx, GXF_ENTRY_ELx, GXF_PABENTRY_ELx, and VBAR_GLx semantics, side effects, and locking behavior; validate early vs. late setup roles and their security implications.
- SPRR policy on current SoCs: Reconstruct the full, current SPRR index-to-permission mappings for EL0/EL2/GLx on A15/M2/M4-class chips; determine runtime mutability and lock/unlock procedures, and how they differ from M1-era mappings.
- SPTM call interface completeness: Enumerate the full set of SPTM subsystems, dispatch tables, call IDs/selectors, argument conventions, and return codes across all gates (main gate, txm_enter, sk_enter); reconcile differences with Apple’s later header releases and document ABI stability.
- Subsystem 0 purpose and coverage: Determine the role of subsystem ID 0 and whether it aggregates multiple services; identify any additional subsystem IDs not visible from XNU and their clients.
- TXM surface characterization: Fully map the TXM selector space, argument schemas, and validation paths; specify call authorization checks and error handling for malformed or adversarial inputs.
- SK→SPTM HVC path semantics: Detail how HVC is implemented/mediated in the absence of a conventional EL3 monitor, including routing, privilege checks, and error isolation between GL1 and GL2.
- SPTM domain model completeness: Specify all SPTM frame types, allowed retyping transitions, cross-domain mapping rules, lifetime/revocation semantics, and enforcement of invariants under concurrency.
- Caller authentication and abuse resistance: Determine how SPTM authenticates/authorizes callers (EL2 kernel, TXM, SK) and prevents spoofing of x16 parameters, subsystem IDs, or selector values by a compromised EL2 kernel.
- Fault and abort handling in GLs: Clarify the conditions that target GXF_PABENTRY, the state captured/reported on GL faults, recovery vs. fatality semantics, and escalation paths back to EL2.
- Concurrency and reentrancy rules: Define whether nested or reentrant GENTER/SVC/HVC invocations are permitted, required locking disciplines, and deadlock/livelock avoidance across EL/GL boundaries.
- Tightbeam IPC security properties: Specify message authentication, confidentiality, replay protection, capability passing, flow control, and DoS resilience; provide a fuzzing corpus and oracle for protocol correctness.
- xnuproxy trust boundary: Document xnuproxy’s authorization policy, per-client isolation, failure containment, and whether it enforces version/compatibility checks on requests to Exclaves.
- Exclave memory safety assumptions: Characterize shared buffer lifetimes, aliasing rules, cacheability and TLB shootdown protocols, DMA visibility, and mitigation of TOCTOU across EL/GL boundaries.
- DMA/IOMMU isolation guarantees: Establish how SPTM policies constrain DART/SART/UAT mappings; verify that device DMA cannot target GL1/GL2 or Exclave memory without explicit policy grants; document per-device domain bindings.
- seL4 use in Exclaves: Determine the extent of seL4 adoption (kernel, userland), Apple-specific modifications, proof-carrying status of the deployed configuration, and any proof gaps introduced by customizations.
- Boot- and update-time trust chain: Describe image authentication, measurement, rollback protection, and version skew handling for SPTM, TXM, SK, and Exclaves; identify what enforces mutual compatibility at boot.
- Performance impact: Quantify costs of GENTER/GEXIT transitions, SPTM mediation of mappings, and SPRR remaps on kernel and I/O hot paths, JIT scenarios, and power/battery metrics.
- Cross-SoC/version divergence: Systematically compare behavior and interfaces across SoCs (A15/M2/M4) and iOS releases (≥18.4), highlighting policy/interface drift and feature flags that affect reverse engineering conclusions.
- Retail vs. SRD behavior: Identify code paths or policies that differ between Security Research Devices and retail devices (entitlements, logging, permissive modes), and their impact on generalizing findings.
- GL hierarchy completeness: Verify whether GL levels beyond GL2 exist or are reserved; catalog which components run at each GL on different devices; define criteria used to assign privilege to GL levels.
- Exception level assignment and virtualization: Precisely document XNU’s EL usage (EL1 vs. EL2), HCR_EL2 configuration, and how virtualization features interact with GLs and SPTM.
- JIT and legacy behaviors: Assess how SPTM/SPRR replace PPL for MAP_JIT, quantify any regressions/constraints imposed on JIT engines and kernel subsystems that previously relied on PPL behavior.
- Interface versioning and negotiation: Determine how SPTM/TXM/SK/Tightbeam negotiate interface versions and handle backward/forward compatibility; define error/reporting when version mismatches occur.
- Tooling and register definitions: Replace reliance on leaked/third-party register descriptions with validated, reproducible specifications; publish scripts/artifacts to replicate symbolication, call tracing, and decoding on multiple firmware versions.
Practical Applications
Immediate Applications
The following applications can be acted on now by security teams, researchers, OS vendors, and educators based on the paper’s reverse engineering of SPTM, TXM, Exclaves, GXF, SPRR, and related calling/IPC patterns.
- SPTM- and GXF-aware threat modeling for modern iOS
- Sectors: software, mobile security, incident response, finance, healthcare (regulated mobile apps)
- Tools/Products/Workflows: updated kill chains accounting for GL2 isolation; playbooks that separate EL2 (XNU) compromise from GL2/Exclave compromise; exploit simulations that test post-kernel-compromise containment
- Assumptions/Dependencies: applies to A15/M2+ devices and iOS versions with SPTM/Exclaves; closed platform limits telemetry available to third parties
- Reverse-engineering extensions that recognize Apple’s guarded levels and SPRR semantics
- Sectors: software tooling, security research
- Tools/Products/Workflows: Ghidra/IDA plugins to decode GENTER/GEXIT paths, SPRR indices, GL vectors (VBAR_GL1), and subsystem descriptors; symbolication improvements for SPTM/TXM/SK binaries
- Assumptions/Dependencies: depends on firmware images, symbolication, and community-maintained Apple register specs (e.g., Asahi m1n1); version-specific offsets
- Interface mapping of SPTM subsystems and gates (GENTER/SVC/HVC) for research and testing
- Sectors: software security, red/blue teams, OEM/SoC vendor research
- Tools/Products/Workflows: SRD-backed harnesses to enumerate x16 encodings, subsystem dispatch tables (e.g., DART/SART/NVME/UAT/CPUTRACE), and access-control outcomes; internal catalogs of callable services and error returns
- Assumptions/Dependencies: SRD or privileged environment required; behavior can change across firmware
- Targeted fuzzing of Exclave IPC surfaces (Tightbeam) and secure-world request handlers (xnuproxy)
- Sectors: software security, mobile app security, OS hardening
- Tools/Products/Workflows: IPC corpus generation, boundary-value fuzzers for Tightbeam message schemas, concurrency tests for xnuproxy queues, coverage collection via LLDB on SRD
- Assumptions/Dependencies: message formats are mostly undocumented; requires careful sandboxing and kernel/GL exception monitoring
- SPTM domain and frame-type policy auditing in OEM labs
- Sectors: OS vendors, device OEMs, SoC designers
- Tools/Products/Workflows: lab tests that validate frame retyping rules, cross-domain mapping constraints, and page table write paths confined to GL2; regression test suites for each firmware release
- Assumptions/Dependencies: internal builds and debug channels are needed; relies on identified rule patterns from current versions
- EDR/DFIR guidance for constrained iOS environments
- Sectors: security operations, managed mobility (MDM), incident response
- Tools/Products/Workflows: updated triage checklists highlighting that many sensitive operations are now outside XNU; emphasis on artifacts and logs around Exclave calls and SPTM traps; refined jailbreak/compromise heuristics
- Assumptions/Dependencies: iOS telemetry is limited for third parties; many signals are only visible to Apple or on SRDs
- Course modules and lab assignments on modern mobile kernel compartmentalization
- Sectors: academia, professional training
- Tools/Products/Workflows: hands-on labs that replicate GENTER parameter discovery, subsystem descriptor parsing, and GL exception vector mapping; comparative studies (PPL vs. SPTM, APRR vs. SPRR)
- Assumptions/Dependencies: educational use may rely on open-source snippets, old builds, or SRD demos
- Secure development guidance for kernel-adjacent components and JIT runtimes
- Sectors: software platforms (browsers, game engines), security runtimes
- Tools/Products/Workflows: WX/JIT policies aligned to SPRR/SPTM constraints; “least-privilege for memory” checklists; CI gates that fail builds if frameworks assume legacy PPL behavior
- Assumptions/Dependencies: app developers don’t control SPTM; guidance is about expectations, not APIs to SPTM
- Benchmarking paper designs for other platforms (Android/Linux/RISC-V) inspired by GXF/SPRR
- Sectors: OS research, SoC architecture teams
- Tools/Products/Workflows: whitepapers and internal prototypes comparing horizontal privilege layers vs. traditional ELs; threat-model templates ported to non-Apple stacks
- Assumptions/Dependencies: immediate usage is analytical (no deployable kernel changes on third-party platforms without substantial engineering)
- Documentation contributions to standards/baselines and coordinated disclosure programs
- Sectors: policy, standards bodies (e.g., CIS, NIST), PSIRTs
- Tools/Products/Workflows: baseline requirements that distinguish kernel vs. GL protection; coordinated disclosure templates specific to GXF components; recommended evidence for reporting
- Assumptions/Dependencies: relies on voluntary adoption by standards bodies; Apple’s private docs remain limited
Long-Term Applications
These opportunities need further research, APIs, or hardware/OS changes before broad deployment.
- Exclave SDKs and APIs for third-party sensitive workloads
- Sectors: finance, healthcare, digital identity, payments, enterprise security
- Tools/Products/Workflows: developer toolchains that compile sensitive modules to Exclaves; IPC stubs (Tightbeam-like) with verified interfaces; lifecycle mgmt (provisioning, attestation, updates)
- Assumptions/Dependencies: would require Apple to expose stable Exclave APIs and policies; review and distribution model for “trusted modules”
- Formal verification of SPTM domain policies and Exclave IPC
- Sectors: academia, high-assurance systems, certification (Common Criteria, ISO/IEC 15408)
- Tools/Products/Workflows: mechanized proofs of memory retyping invariants; model checking for Tightbeam message schemas; seL4-based components with proof-carrying code
- Assumptions/Dependencies: access to specifications; cooperation from platform vendors; verification cost and scalability
- Cross-platform secure IPC frameworks inspired by Tightbeam
- Sectors: software platforms, embedded/IoT, automotive
- Tools/Products/Workflows: language-agnostic IPC IDLs with capability-based security; formally specified message contracts; runtime sandboxes with verifiable marshalling
- Assumptions/Dependencies: performance overheads must be acceptable; adoption hinges on OS integration
- Architecture-level standardization of horizontal guarded levels
- Sectors: semiconductor, ISA governance (ARM, RISC-V), OS vendors
- Tools/Products/Workflows: proposals for ISA extensions akin to SPRR/GXF; reference designs; evaluation on security/performance trade-offs
- Assumptions/Dependencies: requires ecosystem consensus and hardware redesign cycles
- Hardware adoption of SPRR-like permission indirection and page-table protection
- Sectors: SoC design (mobile, automotive safety, industrial control), robotics
- Tools/Products/Workflows: memory-permission indirection units; fast toggles for WX-safe JIT; silicon IP blocks for domain-restricted page-table writes
- Assumptions/Dependencies: silicon lead time (multi-year); toolchain and OS support needed
- High-fidelity mobile EDR with GL/Exclave telemetry
- Sectors: SOC/EDR vendors, regulated enterprises
- Tools/Products/Workflows: anomaly detection on Exclave call graphs and SPTM trap metrics; device attestation enriched with GL health; risk scores for regulated workflows (e.g., wire approvals)
- Assumptions/Dependencies: platform APIs for telemetry are necessary; privacy and power constraints; Apple policy
- Regulatory acceptance of mobile devices for high-trust operations based on compartmentalization guarantees
- Sectors: government eID, finance (high-value approvals), healthcare (PHI handling), energy/OT field ops
- Tools/Products/Workflows: assurance profiles that reference GL2/Exclave isolation; compliance mappings (e.g., to PSD2/SCA, HIPAA); audit procedures validating compartmentalization
- Assumptions/Dependencies: independent evaluations; stable, published guarantees from vendors
- Automated enforcement of memory isolation invariants in developer pipelines
- Sectors: software engineering, DevSecOps
- Tools/Products/Workflows: static/dynamic analyzers that flag code assuming writable page tables; build-time policies aligned to SPTM constraints; runtime monitors for unsafe WX transitions
- Assumptions/Dependencies: needs formalized rules from vendors; integration with compilers and CI/CD
- Secure plugin ecosystems for ML/Crypto modules running in Exclaves
- Sectors: privacy-preserving analytics, on-device ML, fintech cryptography
- Tools/Products/Workflows: plugin packaging, signing, and attestation; key isolation and side-channel mitigations; performance-tuned, zero-copy IPC to/from Exclaves
- Assumptions/Dependencies: Exclave compute and API access for third parties; side-channel research maturity
- Emulation/virtualization frameworks that model GXF/SPTM for testing and education
- Sectors: academia, tool vendors, OS research
- Tools/Products/Workflows: QEMU or custom simulators supporting horizontal levels, SPRR indices, and GENTER/GEXIT semantics; educational sandboxes replicating page-table protection paths
- Assumptions/Dependencies: accurate modeling of proprietary registers; legal and IP considerations
Notes on Feasibility and Dependencies
- Hardware/OS version constraints: Many findings apply to Apple A15/M2+ devices and iOS 17/18+ builds where SPTM and Exclaves are present; behavior is version-specific.
- Access limitations: Deep testing typically requires Apple SRDs or privileged environments; standard consumer devices expose limited telemetry.
- Platform control: Third-party use of Exclaves or SPTM is currently not exposed as public APIs; long-term items assuming SDKs require vendor support.
- Documentation gaps: Reliance on reverse-engineered register definitions and binaries implies maintenance overhead as Apple updates implementations.
- Performance and UX: Stronger isolation may add overhead; long-term EDR/telemetry ideas must balance battery, privacy, and performance.
Glossary
- AArch64: 64-bit execution state of the ARM architecture used by Apple hardware; supports exception levels and virtual memory. "The chips in use in Apple's hardware are based on the AArch64 architecture by ARM."
- AP (Access Permission): Bitfield in ARM translation entries controlling read/write access for privileged and unprivileged modes. "The block entry displays the architecture's default memory access permission mechanism, as represented by the so-called \gls{AP} bits, at bit positions 6 and 7."
- APRR (Access Permissions Remapping Register): Apple-specific register set that remaps page permissions quickly, predecessor to SPRR. "Whilst not officially confirmed, APRR is assumed to denote \gls{APRR}."
- ARM64 Virtualization Host Extensions: ARM feature enabling the OS kernel to run in EL2 without a separate hypervisor. "This is nothing out of the ordinary per se, and can be achieved with techniques like ARM64 Virtualization Host Extensions~\cite{SPRRandGXF:2021}."
- ARMv8-A: ARM architecture version underpinning AArch64, defining translation tables and permissions. "a simplified level one translation table block entry layout for the ARMv8-A architecture (on which the AArch64 execution state is based)."
- EL (Exception Level): ARM privilege levels (EL0–EL3) determining access rights and execution context. "Exception levels are the AArch64 realization of privilege levels."
- ELR (Exception Link Register): ARM system register holding the address of the instruction that caused an exception. "a register holding the address of the instruction causing the exception (\gls{ELR})"
- ESR (Exception Syndrome Register): ARM system register that encodes the cause and details of an exception. "a register holding information on the reason for an exception (\gls{ESR})"
- Exclaves: Apple security feature isolating sensitive operations into guarded domains away from XNU. "This was further advanced with the introduction of Exclaves, a security feature designed to isolate sensitive operations away from XNU."
- FPR (Fast Permission Restrictions): Hardware primitive for rapidly toggling memory permissions without full page table walks. "\gls{FPR} are a hardware primitive used for the fast and efficient remapping of memory permissions, without the need for computationally heavy page table walks."
- GL (Guarded Level): Apple-proprietary lateral privilege levels introduced by GXF, e.g., GL0–GL2. "\gls{SPTM} is be the highest-privileged system component running in \gls{GL} 2"
- GENTER: Apple-proprietary instruction to enter a Guarded Level context. "Entering these GLs is achieved via the Apple-proprietary GENTER instruction (opcode: 0x00201420)"
- GEXIT: Apple-proprietary instruction to exit a Guarded Level context. "whilst exiting is done via GEXIT respectively (opcode: 0x00201420)"
- GXF (Guarded Execution Feature): Apple mechanism adding guarded exception levels with indirection-based permission control. "The \gls{GXF} implements horizontal guarded exception levels in addition to the standard exception levels, and is used to protect sensitive system activity from unrestricted access by XNU."
- HVC (Hypervisor Call): Privileged call used by GL1 components to invoke SPTM services. "GL1 components (the Secure Kernel) may call into \gls{SPTM} directly via \glspl{HVC}."
- IPC (Inter-Process Communication): Communication mechanisms between components/processes; in Exclaves, Tightbeam is used. "We discover multifold ways of communication, most notably xnuproxy as a secure world request handler, and the Tightbeam \gls{IPC} framework."
- NVME: Subsystem related to NVMe storage interfacing within SPTM dispatch. "6 & NVME & 8"
- PXN (Privileged Execute Never): Bit in page table entries preventing execution from privileged levels. "This is implemented via the \gls{UXN} and \gls{PXN} bits at bit position 54 and 53, respectively."
- PPL (Page Protection Layer): Older Apple mechanism restricting kernel writes to sensitive pages via fast permission flips. "As advertised on the Apple Support pages, these systems are intended to replace the previous \gls{PPL}, which we will investigate."
- PTE (Page Table Entry): Entry in a translation table mapping virtual to physical memory with permission bits. "If the relevant bit is set, the memory mapped by the specific \gls{PTE} is marked as non-executable from both the unprivileged/privileged exception levels."
- SART: Apple subsystem for system address translation, used in SPTM dispatch. "5 & SART & 3"
- seL4: High-assurance microkernel whose components are used to realize Exclaves. "which is further supported by our finding of seL4 microkernel components used to realize Exclaves (see \cref{exclaves})."
- SK (Secure Kernel): GL1 microkernel managing Exclave interactions and mediating SPTM requests. "The Exclave ecosystem introduced the \gls{SK}, which handles \gls{SPTM} requests towards Exclaves and serves as a GL1 microkernel."
- SoC (System-on-a-Chip): Integrated hardware platform; certain features apply only to newer Apple SoCs. "With the release of the SPTM and the TXM for A15/M2 or newer \gls{SoC} in 2023"
- SPRR (Shadow Permissions Remapping Register): Apple registers adding indirection to AP/UXN/PXN to enforce guarded-level permissions. "The \glspl{SPRR} are the tool used to implement the \gls{GXF}."
- SPTM (Secure Page Table Monitor): Highest-privileged GL2 component enforcing memory retyping, domains, and protected mappings. "\gls{SPTM} acts as the sole authority regarding memory retyping."
- SRD (Security Research Device): Special Apple device for security research with expanded capabilities. "iPhone 16 \gls{SRD} running iOS 18.5, used for dynamic reverse engineering on recent iOS versions."
- SVC (Supervisor Call): Software interrupt used by lower-privileged code (EL0/GL0) to request privileged services. "An example of this is an EL0 application making \glspl{SVC} to invoke system functionality at a higher privilege level~\cite{ARM_SVC:2025}."
- Tightbeam: Exclaves IPC framework used for secure communication into Exclaves. "Discovery of Tightbeam as an Exclaves secure world \gls{IPC} framework."
- TPIDR (Software Thread ID Register): Thread identifier register available in GLs for context management. "Comparable to standard AArch64 exception levels, the GLs have relevant system registers (such as \gls{TPIDR}, \gls{VBAR}, \gls{ESR}, and \gls{ELR})"
- TXM (Trusted Execution Monitor): GL0 component handling code signing and entitlement verification. "Gapped functionality includes, among others, the \gls{TXM}, responsible for code signing and entitlement verification."
- UAT: Apple subsystem (likely GPU Unified Address Translation) referenced in SPTM dispatch. "7 & UAT & 13"
- UXN (Unprivileged Execute Never): Bit preventing code execution from unprivileged levels for a given PTE. "This is implemented via the \gls{UXN} and \gls{PXN} bits at bit position 54 and 53, respectively."
- VBAR (Vector Base Address Register): Register setting the base address of exception vectors for a given level. "a register that sets the exception base address for exception handling in a specific exception level (\gls{VBAR})"
- XNU: Apple’s hybrid kernel combining Mach and FreeBSD, typically operating monolithically. "The \gls{XNU} kernel is the basis of Apple's operating systems."
- xnuproxy: Secure-world request handler used as part of Exclave communications. "We discover multifold ways of communication, most notably xnuproxy as a secure world request handler"
Collections
Sign up for free to add this paper to one or more collections.