SPTM & TXM -- iOS 17+ Mitigations

Before SPTM (PPL):                After SPTM:
┌────────────────────┐            ┌────────────────────┐
│ EL0: Userspace     │            │ EL0: Userspace     │
├────────────────────┤            ├────────────────────┤
│ EL1: Kernel        │            │ EL1: Kernel        │
│  ├── Normal kernel │            │  └── Cannot touch  │
│  └── PPL (special  │            │      page tables   │
│       mode via APRR│            ├────────────────────┤
│       = page table │            │ EL2: SPTM          │
│       access)      │            │  └── Manages ALL   │
├────────────────────┤            │      page tables +  │
│ EL2: (unused)      │            │      page types     │
├────────────────────┤            ├────────────────────┤
│ EL3: Secure Monitor│            │ EL3: Secure Monitor│
└────────────────────┘            └────────────────────┘

SPTM assigns a type to every physical page:

Page types:
  SPTM_PAGE_FREE        — Not allocated
  SPTM_PAGE_USER        — Mapped to userspace process
  SPTM_PAGE_KERNEL      — Mapped to kernel
  SPTM_PAGE_TABLE       — Used as page table
  SPTM_PAGE_SPTM        — SPTM's own memory
  SPTM_PAGE_TXM         — TXM's memory
  SPTM_PAGE_IOMMU       — I/O memory

Transition rules:
  USER → FREE    : allowed (process exits, page released)
  FREE → KERNEL  : allowed (kernel allocates page)
  USER → KERNEL  : BLOCKED! ← This kills physical UAF escalation
  USER → TABLE   : BLOCKED!
  KERNEL → USER  : Requires explicit transition through SPTM

Pre-SPTM:
  PUAF bug → physical page freed but still mapped in user process
  → Kernel reallocates page for kernel object or page table
  → User process reads/writes kernel data via dangling mapping
  ✓ WORKS

Post-SPTM:
  PUAF bug → physical page freed but still mapped in user process
  → Page type = USER (because still mapped to user)
  → SPTM REFUSES to reallocate as KERNEL or TABLE type
  → Page can only be reused by OTHER user processes
  ✗ Cannot escalate to kernel access
  
  Partial: user→user PUAF still possible
  → Read/write other processes' memory
  → But NOT kernel memory

Kernel CANNOT:
  - Write to page table pages directly
  - Change page types
  - Map arbitrary physical addresses

Kernel CAN:
  - Request SPTM to create/remove mappings via API:
    sptm_map_page(pmap, va, pa, prot, ...)
    sptm_unmap_page(pmap, va)
  
  SPTM validates:
    - Source page type matches request
    - Permissions are allowed
    - No security-violating transitions

Pre-TXM:
  Binary execution → AMFI (kernel kext) → amfid (userspace)
  → CoreTrust (kernel kext) → certificate validation
  → Kernel trusts result → allow/deny

Post-TXM:
  Binary execution → Kernel asks TXM (EL2) to verify
  → TXM independently verifies code signature
  → TXM returns decision to kernel
  → Kernel CANNOT override TXM decision

Pre-TXM:
  Kernel r/w → patch AMFI checks → bypass code signing
  Kernel r/w → inject trust cache → run unsigned code
  ✓ Kernel exploit sufficient

Post-TXM:
  Kernel r/w → CANNOT patch TXM (runs at EL2)
  Kernel r/w → Trust cache injection BLOCKED (TXM manages trust caches)
  ✗ Kernel exploit NOT sufficient
  Need: TXM vulnerability + SPTM vulnerability + kernel vulnerability

SPTM is software (runs at EL2) → it can have bugs
  - Logic bugs in page type transition validation
  - Memory corruption in SPTM's own data structures
  - Race conditions in concurrent page operations
  
But: the SPTM codebase is very small, highly audited

- Undocumented hardware features (a la Operation Triangulation)
- DMA attacks (if IOMMU is not properly configured)
- Side channels (timing, power analysis)

- SPTM/kernel interface bugs
- Information leaks from EL2 → EL1
- Boot chain attacks (compromise before SPTM initialized)

iOS 17-18 on A15+ devices:
  - No public SPTM/TXM bypass
  - No public jailbreak
  - Difficulty level: extreme
  
iOS 17-18 on A14 and older:
  - Still uses PPL (not SPTM)
  - PPL bypasses still applicable
  - Jailbreak possible if a kernel exploit exists