; Example: indirect function pointer stored in a struct ; suppose X1 contains a function pointer PACDA X1, X2 ; sign data pointer X1 with context X2 STR X1, [X0] ; store signed pointer

; later retrieval: LDR X1, [X0] AUTDA X1, X2 ; authenticate & strip BLR X1 ; branch to valid target

; Example: stripping for comparison (unsafe) LDR X1, [X0] XPACI X1 ; strip PAC (instruction domain) CMP X1, #some_label_address BEQ matched_label

</details>

<details>
<summary>Example</summary>
バッファオーバーフローがスタック上のリターンアドレスを上書きする。攻撃者はターゲットとなるガジェットのアドレスを書き込むが、正しい PAC を計算できない。関数がリターンすると、CPU の `AUTIA` 命令が PAC の不一致によりフォルトを起こす。チェインは失敗する。
Project Zero の A12 (iPhone XS) に関する解析は、Apple の PAC がどのように使われているか、そして攻撃者がメモリの read/write プリミティブを持つ場合に PAC を偽造する方法を示した。
</details>


### 9. **Branch Target Identification (BTI)**
**Introduced with ARMv8.5 (later hardware)**
BTI は間接分岐ターゲットをチェックするハードウェア機能で、`blr` や間接的な call/jump を実行する際に、ターゲットが **BTI landing pad**（`BTI j` または `BTI c`）で始まっている必要がある。landing pad のないガジェットアドレスにジャンプすると例外が発生する。

LLVM の実装ノートは BTI 命令の三つのバリアントと、それらがどの分岐タイプにマップされるかを示している。

| BTI Variant | What it permits (which branch types) | Typical placement / use case |
|-------------|----------------------------------------|-------------------------------|
| **BTI C** | *call* スタイルの間接分岐のターゲット（例: `BLR`、または `BR` が X16/X17 を使う場合） | 間接的に呼ばれる可能性のある関数のエントリに置く |
| **BTI J** | *jump* スタイルの分岐のターゲット（例: tail call に使われる `BR`） | ジャンプテーブルや tail-call で到達可能なブロックの先頭に置く |
| **BTI JC** | C と J の両方として働く | call でも jump でもターゲットになりうる場所に使える |

- branch target enforcement でコンパイルされたコードでは、コンパイラは有効な間接分岐ターゲット（関数の先頭やジャンプで到達可能なブロック）ごとに BTI 命令（C、J、または JC）を挿入し、間接分岐がそれらの場所にしか成功しないようにする。
- **Direct branches / calls**（つまり固定アドレスの `B`, `BL`）は BTI による制限を受けない。これはコードページが信頼されており攻撃者がそれらを変更できないという前提に基づいている（したがって direct branches は安全と見なされる）。
- また、**RET / return** 命令は一般に BTI の制限を受けない。返り先アドレスは PAC や return signing 機構で保護されているためである。

#### Mechanism and enforcement

- CPU が “guarded / BTI-enabled” とマークされたページ内で **間接分岐 (`BLR` / `BR`)** をデコードすると、ターゲットアドレスの最初の命令が許可された BTI（C、J、または JC）であるかをチェックする。そうでない場合は **Branch Target Exception** が発生する。
- BTI 命令のエンコーディングは、以前の ARM バージョンで NOP に予約されていたオペコードを再利用するよう設計されている。したがって BTI 対応バイナリは後方互換性を保ち、BTI 非対応ハードウェアではそれらの命令が NOP として機能する。
- BTI を追加するコンパイラパスは、必要な場所にのみ挿入する：間接的に呼ばれる可能性のある関数、あるいはジャンプでターゲットになり得る基本ブロック。
- いくつかのパッチや LLVM のコードは、BTI が *すべての* 基本ブロックに挿入されるわけではなく、スイッチやジャンプテーブルなどからの潜在的な分岐先となるものだけに挿入されることを示している。

#### BTI + PAC synergy

PAC はポインタ値（ソース）を保護し、間接呼び出し／リターンのチェインが改竄されていないことを保証する。

BTI は有効なポインタであっても、適切にマークされたエントリポイントのみをターゲットにできるようにする。

これらを組み合わせると、攻撃者は正しい PAC を持つ有効なポインタに加え、ターゲットに BTI が配置されている必要があり、ガジェット構築の難易度が上がる。

#### Example


<details>
<summary>Example</summary>
あるエクスプロイトが `0xABCDEF` にある、`BTI c` で始まらないガジェットにピボットしようとする。CPU は `blr x0` を実行した際にターゲットをチェックし、最初の命令が有効な landing pad を含まないためフォルトする。多くのガジェットは BTI プレフィックスを持たなければ使えなくなる。
</details>


### 10. **Privileged Access Never (PAN) & Privileged Execute Never (PXN)**
**Introduced in more recent ARMv8 extensions / iOS support (for hardened kernel)**

#### PAN (Privileged Access Never)

- **PAN** は **ARMv8.1-A** で導入された機能で、**privileged code**（EL1 または EL2）が **user-accessible (EL0)** とマークされたメモリを **読み書き** することを防ぐ（PAN を明示的に無効にしない限り）。
- 目的は：カーネルが騙されたり妥協されたりしても、カーネルがユーザ空間のポインタを任意に逆参照できないようにして、**ret2usr** スタイルのエクスプロイトやユーザ制御バッファの悪用を減らすこと。
- PAN が有効な場合（PSTATE.PAN = 1）、“accessible at EL0” とされる仮想アドレスに対する特権モードの load/store 命令はパーミッションフォルトを引き起こす。
- カーネルが正当にユーザ空間メモリへアクセスする必要がある場合（例: ユーザバッファへのデータコピー）、カーネルは一時的に PAN を無効化するか（または“unprivileged load/store” 命令を使う）してアクセスを許可する必要がある。
- Linux on ARM64 では、PAN サポートは約 2015 年に導入され、カーネルのパッチはこの機能の検出を追加し、`get_user` / `put_user` 等を PAN をクリアするバリアントに置き換えた。

**重要なニュアンス / 制限 / バグ**
- Siguza らが指摘したように、ARM の設計における仕様上のバグ（あるいは曖昧な挙動）により、**execute-only user mappings**（`--x`）は **PAN をトリガーしない場合がある**。つまり、ユーザページが実行可能で読み取り許可がない場合、カーネルの読み取り試行が PAN をバイパスする可能性がある。これはアーキテクチャが “accessible at EL0” を判定する際に読み取り可能性を要求しており、実行可能性だけでは不十分と見なすためである。これにより、特定の構成では PAN を回避できる。
- そのため、もし iOS / XNU が execute-only なユーザページを許可している（JIT やコードキャッシュ設定などで）なら、カーネルは PAN が有効でもそれらから読み取ってしまう可能性がある。これは一部の ARMv8+ システムで知られている微妙な攻撃対象である。

#### PXN (Privileged eXecute Never)

- **PXN** はページテーブルのフラグ（leaf / block エントリ内）で、ページが **特権モードで実行不可** であることを示す（つまり EL1 実行時にそのページは実行できない）。
- PXN は、カーネルや他の特権コードがユーザ空間ページからのジャンプや命令実行を行うのを防ぐ。結果として、privileged レベルでの制御フローをユーザメモリに逸らすことを止める。
- PAN と組み合わせると次が保証される：
  1. カーネルはデフォルトでユーザ空間データを読み書きできない（PAN）
  2. カーネルはユーザ空間コードを実行できない（PXN）
- ARMv8 のページテーブルフォーマットでは、leaf エントリに `PXN` ビット（および unprivileged 用の `UXN`）が属性ビットとして存在する。

したがって、カーネルにユーザメモリを指す破損した関数ポインタがあっても、ジャンプしようとすれば PXN ビットによりフォルトが発生する。

#### Memory-permission model & how PAN and PXN map to page table bits

PAN / PXN の動作を理解するには、ARM の翻訳とパーミッションモデルがどのように機能するかを見る必要がある（簡略化）:

- 各ページまたはブロックエントリは、読み書きや特権／非特権区別のための **AP[2:1]** と、実行禁止制限のための **UXN / PXN** ビットなどの属性フィールドを持つ。
- PSTATE.PAN が 1（有効）であるとき、ハードウェアは意味論を修正して強制する：EL0 により “accessible” とマークされたページへの特権アクセスは拒否（フォルト）される。
- 前述のバグのため、読み取り権がない実行専用ページは、実装によっては “accessible at EL0” と見なされず、PAN を迂回してカーネルがそれらから読み取れる場合がある。
- ページに PXN ビットが設定されていると、たとえ高い特権レベルからの命令フェッチであっても実行が禁止される。

#### Kernel usage of PAN / PXN in a hardened OS (e.g. iOS / XNU)

ハード化されたカーネル設計（Apple が採用している可能性のあるもの）では：

- カーネルはデフォルトで PAN を有効にする（よって特権コードは制約される）。
- 正当にユーザバッファを読み書きする経路（syscall のデータコピー、I/O、ユーザポインタの read/write など）では、カーネルは一時的に **PAN を無効化** するか、ユーザメモリアクセスを許す特別な命令を使う。
- ユーザデータアクセスが終わったら、PAN を再度有効にしなければならない。
- PXN はページテーブル経由で強制される：ユーザページには PXN = 1 が設定され（カーネルはそこを実行できない）、カーネルページには PXN が設定されない（カーネルコードは実行可能）。
- カーネルは、処理のどの経路でも実行フローがユーザメモリ領域へ移ってしまわないように注意する必要がある（そうでなければ PXN をバイパスすることになる）。したがって「ユーザ制御のシェルコードにジャンプする」ことを前提にしたエクスプロイトチェインは阻止される。

前述の execute-only ページによる PAN バイパスのため、実際のシステムでは Apple は execute-only user pages を無効にするか、仕様上の弱点を回避するための修正を行っている可能性がある。

#### Attack surfaces, bypasses, and mitigations

- **PAN bypass via execute-only pages**: 前述のように、仕様の隙間により execute-only（読み取り許可なし、実行のみ）になっているユーザページは PAN をトリガーしない場合があり、これにより攻撃者は通常とは異なる経路でデータを渡すことができる。
- **Temporal window exploit**: カーネルが必要以上に長い間 PAN を無効にする場合、そのウィンドウを狙ったレースや悪意ある経路が不正なユーザメモリアクセスを誘発する可能性がある。
- **Forgotten re-enable**: PAN を再有効化し忘れるコードパスがあると、以降のカーネル操作が誤ってユーザメモリにアクセスしてしまう。
- **Misconfiguration of PXN**: ページテーブルがユーザページに PXN を設定していなかったり、ユーザコードページを誤ってマップしていると、カーネルがユーザ空間コードを実行させられてしまう可能性がある。
- **Speculation / side-channels**: 推測実行に起因するバイパスと同様に、PAN / PXN チェックの一時的な違反を引き起こすマイクロアーキテクチャ的な副作用が存在するかもしれない（ただしこうした攻撃は CPU 設計に大きく依存する）。
- **Complex interactions**: JIT、shared memory、just-in-time code regions のような高度な機能では、カーネルは特定のメモリアクセスやユーザマップ領域での実行を細かく許可する必要があり、PAN/PXN 制約下でそれらを安全に設計するのは難しい。

#### Example

<details>
<summary>Code Example</summary>
以下は、ユーザメモリアクセスのために PAN を有効／無効化する擬似アセンブリ列と、どのようにフォルトが発生しうるかを示す例である。
</details>
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">  </span></div>

// Suppose kernel entry point, PAN is enabled (privileged code cannot access user memory by default)

; Kernel receives a syscall with user pointer in X0 ; wants to read an integer from user space mov X1, X0 ; X1 = user pointer

; disable PAN to allow privileged access to user memory MSR PSTATE.PAN, #0 ; clear PAN bit, disabling the restriction

ldr W2, [X1] ; now allowed load from user address

; re-enable PAN before doing other kernel logic MSR PSTATE.PAN, #1 ; set PAN

; ... further kernel work ...

; Later, suppose an exploit corrupts a pointer to a user-space code page and jumps there BR X3 ; branch to X3 (which points into user memory)

; Because the target page is marked PXN = 1 for privileged execution, ; the CPU throws an exception (fault) and rejects execution

If the kernel had **not** set PXN on that user page, then the branch might succeed — which would be insecure.

If the kernel forgets to re-enable PAN after user memory access, it opens a window where further kernel logic might accidentally read/write arbitrary user memory.

If the user pointer is into an execute-only page (user page with only execute permission, no read/write), under the PAN spec bug, `ldr W2, [X1]` might **not** fault even with PAN enabled, enabling a bypass exploit, depending on implementation.

</details>

<details>
<summary>例</summary>
A kernel vulnerability tries to take a user-provided function pointer and call it in kernel context (i.e. `call user_buffer`). Under PAN/PXN, that operation is disallowed or faults.
</details>

---

### 11. **Top Byte Ignore (TBI) / Pointer Tagging**
**Introduced in ARMv8.5 / newer (or optional extension)**
TBI means the top byte (most-significant byte) of a 64-bit pointer is ignored by address translation. This lets OS or hardware embed **tag bits** in the pointer’s top byte without affecting the actual address.

- TBI stands for **Top Byte Ignore** (sometimes called *Address Tagging*). It is a hardware feature (available in many ARMv8+ implementations) that **ignores the top 8 bits** (bits 63:56) of a 64-bit pointer when performing **address translation / load/store / instruction fetch**.
- In effect, the CPU treats a pointer `0xTTxxxx_xxxx_xxxx` (where `TT` = top byte) as `0x00xxxx_xxxx_xxxx` for the purposes of address translation, ignoring (masking off) the top byte. The top byte can be used by software to store **metadata / tag bits**.
- This gives software “free” in-band space to embed a byte of tag in each pointer without altering which memory location it refers to.
- The architecture ensures that loads, stores, and instruction fetch treat the pointer with its top byte masked (i.e. tag stripped off) before performing the actual memory access.

Thus TBI decouples the **logical pointer** (pointer + tag) from the **physical address** used for memory operations.

#### Why TBI: ユースケースと動機

- **Pointer tagging / metadata**: You can store extra metadata (e.g. object type, version, bounds, integrity tags) in that top byte. When you later use the pointer, the tag is ignored at hardware level, so you don’t need to strip manually for the memory access.
- **Memory tagging / MTE (Memory Tagging Extension)**: TBI is the base hardware mechanism that MTE builds on. In ARMv8.5, the **Memory Tagging Extension** uses bits 59:56 of the pointer as a **logical tag** and checks it against an **allocation tag** stored in memory.
- **Enhanced security & integrity**: By combining TBI with pointer authentication (PAC) or runtime checks, you can force not just the pointer value but also the tag to be correct. An attacker overwriting a pointer without the correct tag will produce a mismatched tag.
- **Compatibility**: Because TBI is optional and tag bits are ignored by hardware, existing untagged code continues to operate normally. The tag bits effectively become “don’t care” bits for legacy code.

#### Example
<details>
<summary>例</summary>
A function pointer included a tag in its top byte (say `0xAA`). An exploit overwrites the pointer low bits but neglects the tag, so when the kernel verifies or sanitizes, the pointer fails or is rejected.
</details>

---

### 12. **Page Protection Layer (PPL)**
**Introduced in late iOS / modern hardware (iOS ~17 / Apple silicon / high-end models)** (some reports show PPL circa macOS / Apple silicon, but Apple is bringing analogous protections to iOS)

- PPL is designed as an **intra-kernel protection boundary**: even if the kernel (EL1) is compromised and has read/write capabilities, **it should not be able to freely modify** certain **sensitive pages** (especially page tables, code-signing metadata, kernel code pages, entitlements, trust caches, etc.).
- It effectively creates a **“kernel within the kernel”** — a smaller trusted component (PPL) with **elevated privileges** that alone can modify protected pages. Other kernel code must call into PPL routines to effect changes.
- This reduces the attack surface for kernel exploits: even with full arbitrary R/W/execute in kernel mode, exploit code must also somehow get into the PPL domain (or bypass PPL) to modify critical structures.
- On newer Apple silicon (A15+ / M2+), Apple is transitioning to **SPTM (Secure Page Table Monitor)**, which in many cases replaces PPL for page-table protection on those platforms.

Here’s how PPL is believed to operate, based on public analysis:

#### Use of APRR / permission routing (APRR = Access Permission ReRouting)

- Apple hardware uses a mechanism called **APRR (Access Permission ReRouting)**, which allows page table entries (PTEs) to contain small indices, rather than full permission bits. Those indices are mapped via APRR registers to actual permissions. This allows dynamic remapping of permissions per domain.
- PPL leverages APRR to segregate privilege within kernel context: only the PPL domain is permitted to update the mapping between indices and effective permissions. That is, when non-PPL kernel code writes a PTE or tries to flip permission bits, the APRR logic disallows it (or enforces read-only mapping).
- PPL code itself runs in a restricted region (e.g. `__PPLTEXT`) which is normally non-executable or non-writable until entry gates temporarily allow it. The kernel calls PPL entry points (“PPL routines”) to perform sensitive operations.

#### Gate / Entry & Exit

- When the kernel needs to modify a protected page (e.g. change permissions of a kernel code page, or modify page tables), it calls into a **PPL wrapper** routine, which does validation and then transitions into the PPL domain. Outside that domain, the protected pages are effectively read-only or non-modifiable by the main kernel.
- During PPL entry, the APRR mappings are adjusted so that memory pages in the PPL region are set to **executable & writable** within PPL. Upon exit, they are returned to read-only / non-writable. This ensures that only well-audited PPL routines can write to protected pages.
- Outside PPL, attempts by kernel code to write to those protected pages will fault (permission denied) because the APRR mapping for that code domain doesn’t permit writing.

#### Protected page categories

The pages that PPL typically protects include:

- Page table structures (translation table entries, mapping metadata)
- Kernel code pages, especially those containing critical logic
- Code-sign metadata (trust caches, signature blobs)
- Entitlement tables, signature enforcement tables
- Other high-value kernel structures where a patch would allow bypassing signature checks or credentials manipulation

The idea is that even if the kernel memory is fully controlled, the attacker cannot simply patch or rewrite these pages, unless they also compromise PPL routines or bypass PPL.


#### Known Bypasses & Vulnerabilities

1. **Project Zero’s PPL bypass (stale TLB trick)**

- A public writeup by Project Zero describes a bypass involving **stale TLB entries**.
- The idea:

1. Allocate two physical pages A and B, mark them as PPL pages (so they are protected).
2. Map two virtual addresses P and Q whose L3 translation table pages come from A and B.
3. Spin a thread to continuously access Q, keeping its TLB entry alive.
4. Call `pmap_remove_options()` to remove mappings starting at P; due to a bug, the code mistakenly removes the TTEs for both P and Q, but only invalidates the TLB entry for P, leaving Q’s stale entry live.
5. Reuse B (page Q’s table) to map arbitrary memory (e.g. PPL-protected pages). Because the stale TLB entry still maps Q’s old mapping, that mapping remains valid for that context.
6. Through this, the attacker can put writable mapping of PPL-protected pages in place without going through PPL interface.

- This exploit required fine control of physical mapping and TLB behavior. It demonstrates that a security boundary relying on TLB / mapping correctness must be extremely careful about TLB invalidations and mapping consistency.

- Project Zero commented that bypasses like this are subtle and rare, but possible in complex systems. Still, they regard PPL as a solid mitigation.

2. **Other potential hazards & constraints**

- If a kernel exploit can directly enter PPL routines (via calling the PPL wrappers), it might bypass restrictions. Thus argument validation is critical.
- Bugs in the PPL code itself (e.g. arithmetic overflow, boundary checks) can allow out-of-bounds modifications inside PPL. Project Zero observed that such a bug in `pmap_remove_options_internal()` was exploited in their bypass.
- The PPL boundary is irrevocably tied to hardware enforcement (APRR, memory controller), so it's only as strong as the hardware implementation.



#### Example
<details>
<summary>コード例</summary>
Here’s a simplified pseudocode / logic showing how a kernel might call into PPL to modify protected pages:
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```c
// In kernel (outside PPL domain)
function kernel_modify_pptable(pt_addr, new_entry) {
// validate arguments, etc.
return ppl_call_modify(pt_addr, new_entry)  // call PPL wrapper
}

// In PPL (trusted domain)
function ppl_call_modify(pt_addr, new_entry) {
// temporarily enable write access to protected pages (via APRR adjustments)
aprr_set_index_for_write(PPL_INDEX)
// perform the modification
*pt_addr = new_entry
// restore permissions (make pages read-only again)
aprr_restore_default()
return success
}

// If kernel code outside PPL does:
*pt_addr = new_entry  // a direct write
// It will fault because APRR mapping for non-PPL domain disallows write to that page

The kernel can do many normal operations, but only through ppl_call_* routines can it change protected mappings or patch code.

// pointer P points into A with tag T1 P = (T1 << 56) | 0x1000

// Valid store *(P + offset) = value // tag T1 matches allocation → allowed

// Overflow attempt: P’ = P + size_of_A (into B region) *(P' + delta) = value → pointer includes tag T1 but memory block has tag T2 → mismatch → fault

// Free A, allocator retags it to T3 free(A)

// Use-after-free: *(P) = value → pointer still has old tag T1, memory region is now T3 → mismatch → fault

</details>

#### 制約と課題

- **Intrablock overflows**: オーバーフローが同一の割り当て内に留まり（境界を越えない）、tag が同じままの場合、tag mismatch は検出できない。
- **Tag width limitation**: tag に使えるビット数は限られている（例：4 ビットや小さなドメイン）—名前空間が制約される。
- **Side-channel leaks**: tag ビットが（cache / speculative execution 経由で）leaked できる場合、攻撃者は有効な tags を学び回避できる可能性がある。Apple の tag confidentiality enforcement はこれを緩和することを目的としている。
- **Performance overhead**: 各 load/store ごとの tag チェックはコストを追加する。Apple はハードウェア最適化でオーバーヘッドを低く抑える必要がある。
- **Compatibility & fallback**: 古いハードウェアや EMTE をサポートしない部分ではフォールバックが必要になる。Apple は MIE がサポートされるデバイスでのみ有効になると主張している。
- **Complex allocator logic**: allocator は tags の管理、retagging、境界の整列、mis-tag 衝突回避を行う必要がある。allocator ロジックのバグは新たな脆弱性を生む可能性がある。
- **Mixed memory / hybrid areas**: 一部のメモリは untagged（レガシー）のまま残る可能性があり、相互運用がより複雑になる。
- **Speculative / transient attacks**: 多くのマイクロアーキテクチャ保護と同様に、speculative execution や micro-op fusion によりチェックを一時的に回避したり tag ビットを leak したりする可能性がある。
- **Limited to supported regions**: Apple は EMTE をカーネルやセキュリティ重要サブシステムなど選択的で高リスクな領域にのみ適用する可能性があり、全域には及ばない場合がある。



---

## Key enhancements / differences compared to standard MTE

以下は Apple が強調する改善点と変更点:

| Feature | Original MTE | EMTE (Apple’s enhanced) / MIE |
|---|---|---|
| **Check mode** | Supports synchronous and asynchronous modes. In async, tag mismatches are reported later (delayed)| Apple insists on **synchronous mode** by default—tag mismatches are caught immediately, no delay/race windows allowed.|
| **Coverage of non-tagged memory** | Accesses to non-tagged memory (e.g. globals) may bypass checks in some implementations | EMTE requires that accesses from a tagged region to non-tagged memory also validate tag knowledge, making it harder to bypass by mixing allocations.|
| **Tag confidentiality / secrecy** | Tags might be observable or leaked via side channels | Apple adds **Tag Confidentiality Enforcement**, which attempts to prevent leakage of tag values (via speculative side-channels etc.).|
| **Allocator integration & retagging** | MTE leaves much of allocator logic to software | Apple’s secure typed allocators (kalloc_type, xzone malloc, etc.) integrate with EMTE: when memory is allocated or freed, tags are managed at fine granularity.|
| **Always-on by default** | In many platforms, MTE is optional or off by default | Apple enables EMTE / MIE by default on supported hardware (e.g. iPhone 17 / A19) for kernel and many user processes.|

Apple はハードウェアとソフトウェアスタックの両方を制御しているため、EMTE を厳密に適用し、パフォーマンス上の問題を避け、side-channel の穴を閉じることができる。

---

## How EMTE works in practice (Apple / MIE)

以下は Apple の MIE セットアップ下で EMTE がどのように動作するかの上位レベルの説明:

1. **Tag assignment**
- メモリが割り当てられるとき（カーネルや secure allocators を介したユーザ空間など）、そのブロックに**secret tag** が割り当てられる。
- ユーザやカーネルに返されるポインタはその tag を上位ビットに含む（TBI / top byte ignore メカニズムを使用）。

2. **Tag checking on access**
- ポインタを使って load/store が実行されるたびに、ハードウェアはポインタの tag がメモリブロックの tag（allocation tag）と一致するかをチェックする。ミスマッチなら即座にフォルトする（同期的であるため）。
- 同期的であるため、検出の遅延ウィンドウは存在しない。

3. **Retagging on free / reuse**
- メモリが free されると、allocator はブロックの tag を変更する（古いポインタの tag はもはや一致しない）。
- use-after-free ポインタは古い tag を持っているため、アクセス時にミスマッチとなる。

4. **Neighbor-tag differentiation to catch overflows**
- 隣接する割り当てには異なる tags が付与される。バッファオーバーフローが隣のメモリに流出すると tag mismatch によりフォルトが発生する。
- これは境界を越える小さなオーバーフローを検出するのに特に有効である。

5. **Tag confidentiality enforcement**
- 攻撃者が tag を学習して正しい tag を持つポインタを作成できないように、Apple は tag 値の leaked を防ぐ必要がある。
- そのために（speculative side-channels 等を通じた）情報漏洩を避けるための保護を含めている。

6. **Kernel and user-space integration**
- Apple は EMTE をユーザ空間だけでなくカーネル / OS 重要コンポーネントにも適用している（カーネルのメモリ破壊から保護するため）。
- ハードウェア / OS は、カーネルがユーザ空間のために実行している場合でも tag ルールが適用されるように保証する。

EMTE は MIE に組み込まれているため、Apple は主要な攻撃面に対して EMTE を同期モードで有効にしており、オプトインやデバッグモードとしてではなく常時有効にしている。

---

## Exception handling in XNU

例外（例：`EXC_BAD_ACCESS`, `EXC_BAD_INSTRUCTION`, `EXC_CRASH`, `EXC_ARM_PAC`, など）が発生すると、XNU カーネルの Mach レイヤがそれを UNIX スタイルの signal（`SIGSEGV`, `SIGBUS`, `SIGILL`, ... のような）に変換される前に介入する責任を負う。

このプロセスは、ユーザ空間に到達するか BSD signal に変換されるまでに複数の例外伝播と処理レイヤを経る。

### Exception Flow (High-Level)

1.  **CPU triggers a synchronous exception**（例：無効なポインタ参照、PAC failure、illegal instruction 等）。

2.  **Low-level trap handler** が動作する（XNU ソースの `trap.c`, `exception.c`）。

3.  トラップハンドラは **`exception_triage()`** を呼び出す。これは Mach 例外処理の中核である。

4.  `exception_triage()` は例外をどのようにルーティングするかを決定する:

-   最初に **thread の exception port** へ。

-   次に **task の exception port** へ。

-   次に **host の exception port**（多くの場合 `launchd` や `ReportCrash`）。

これらのポートのいずれも例外を処理しない場合、カーネルは:

-   **それを BSD signal に変換する**（ユーザ空間プロセス向け）。

-   **panic** を引き起こす（カーネル空間の例外の場合）。

### Core Function: `exception_triage()`

関数 `exception_triage()` は Mach 例外を処理するハンドラのチェーンに沿ってルーティングし、いずれかが処理するか最終的に致命的になるまで進める。これは `osfmk/kern/exception.c` に定義されている。
<div class="codeblock_filename_container"><span class="codeblock_filename_inner hljs">c</span></div>

```c
void exception_triage(exception_type_t exception, mach_exception_data_t code, mach_msg_type_number_t codeCnt);

典型的なコールフロー:

exception_triage() └── exception_deliver() ├── exception_deliver_thread() ├── exception_deliver_task() └── exception_deliver_host()

If all fail → handled by bsd_exception() → translated into a signal like SIGSEGV.

Exception Ports

各 Mach オブジェクト (thread, task, host) は、例外メッセージが送られる exception ports を登録できます。

これらは API によって定義されています：

task_set_exception_ports()
thread_set_exception_ports()
host_set_exception_ports()

各例外ポートは次を持つ:

• mask（どの例外を受け取りたいか）
• port name（メッセージを受け取る Mach port）
• behavior（カーネルがメッセージを送る方法）
• flavor（含めるスレッド状態の種類）

デバッガと例外処理

debugger（例: LLDB）はターゲットのタスクやスレッドに exception port を設定する。通常は task_set_exception_ports() を使用する。

例外が発生した場合:

• Mach メッセージがデバッガプロセスに送られる。
• デバッガは例外を handle（再開、レジスタ変更、命令をスキップ）するか、handle しない かを決められる。
• デバッガが処理しなければ、例外は次のレベルに伝播する（thread → task → host）。

Flow of EXC_BAD_ACCESS

1. スレッドが無効なポインタをデリファレンスする → CPU が Data Abort を発生させる。

2. カーネルトラップハンドラが exception_triage(EXC_BAD_ACCESS, ...) を呼ぶ。

3. メッセージは以下に送られる:

• Thread port → （デバッガがブレークポイントを傍受できる）。

• デバッガが無視すると → Task port → （プロセスレベルのハンドラ）。

• 無視されると → Host port（通常は ReportCrash）。

4. 誰も処理しなければ → bsd_exception() が SIGSEGV に変換する。

PAC Exceptions

Pointer Authentication (PAC) が失敗（署名不一致）すると、特別な Mach 例外が発生する:

• EXC_ARM_PAC（タイプ）
• コードには詳細（例: key type、pointer type）が含まれることがある。

バイナリにフラグ TFRO_PAC_EXC_FATAL が設定されていると、カーネルは PAC 失敗を致命的と扱い、デバッガの傍受をバイパスする。これは攻撃者がデバッガを使って PAC チェックを回避するのを防ぐためで、platform binaries に対して有効になる。

Software Breakpoints

ソフトウェアブレークポイント（x86 の int3、ARM64 の brk）は意図的なフォルトを発生させることで実装される。
デバッガはこれを exception port 経由でキャッチする:

• 命令ポインタやメモリを変更する。
• 元の命令を復元する。
• 実行を再開する。

同じ仕組みで PAC 例外を「キャッチ」することができる --- ただし TFRO_PAC_EXC_FATAL が設定されている場合は例外は決してデバッガに到達しない。

Conversion to BSD Signals

誰も例外を受け入れない場合:

• カーネルは task_exception_notify() → bsd_exception() を呼ぶ。

• これが Mach 例外をシグナルにマッピングする:

Key Files in XNU Source

• osfmk/kern/exception.c → exception_triage()、exception_deliver_*() のコア。
• bsd/kern/kern_sig.c → シグナル配送ロジック。
• osfmk/arm64/trap.c → 低レベルのトラップハンドラ。
• osfmk/mach/exc.h → 例外コードと構造体。
• osfmk/kern/task.c → タスクの例外ポート設定。

Old Kernel Heap (Pre-iOS 15 / Pre-A12 era)

カーネルは固定サイズの「zones」に分かれた zone allocator（kalloc）を使用していた。各 zone は単一のサイズクラスの割り当てのみを格納する。

スクリーンショットから:

動作の仕組み:

• 各割り当て要求は最も近いゾーンサイズに切り上げられる。 （例: 50 バイトの要求は kalloc.64 ゾーンに入る）。
• 各ゾーンのメモリは freelist で管理されていた — カーネルが解放したチャンクはそのゾーンに戻された。
• もし 64 バイトバッファをオーバーフローすると、同じゾーン内の次のオブジェクトを上書きしてしまう。

このため heap spraying / feng shui が非常に効果的だった: 同じサイズクラスの割り当てをスプレーすれば、オブジェクトの隣接関係を予測できた。

The freelist

各 kalloc ゾーン内では、解放されたオブジェクトはシステムに直接返されず、freelist（利用可能チャンクの連結リスト）に入れられていた。

• チャンクが解放されると、カーネルはそのチャンクの先頭にポインタを書き込む → 同じゾーンの次のフリーチャンクのアドレス。

• ゾーンは最初のフリーチャンクを指す HEAD ポインタを保持する。

• 割り当ては常に現在の HEAD を使う:

1. HEAD を pop（そのメモリを呼び出し元に返す）。

2. HEAD = HEAD->next（解放済みチャンクのヘッダに格納されている）。

• 解放はチャンクをプッシュする:

• freed_chunk->next = HEAD

• HEAD = freed_chunk

つまり freelist は、解放されたメモリ自身の内部に構築された単なる連結リストだった。

Normal state:

Zone page (64-byte chunks for example):
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]

Freelist view:
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
(next ptrs stored at start of freed chunks)

freelistの悪用

free chunkの最初の8バイトが freelist pointer であるため、攻撃者はそれを改ざんできます:

1. Heap overflow into an adjacent freed chunk → overwrite its “next” pointer.

2. Use-after-free write into a freed object → overwrite its “next” pointer.

Then, on the next allocation of that size:

• アロケータは破損したチャンクをポップする。
• 攻撃者が提供した “next” pointer を辿る。
• 任意のメモリへのポインタを返し、fake object primitives や targeted overwrite を可能にする。

Visual example of freelist poisoning:

Before corruption:
HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL

After attacker overwrite of F1->next:
HEAD ──► [ F1 ]
(next) ──► 0xDEAD_BEEF_CAFE_BABE  (attacker-chosen)

Next alloc of this zone → kernel hands out memory at attacker-controlled address.

この freelist 設計はハードニング前における悪用を非常に効果的にしていました：heap sprays による予測可能な隣接、raw pointer freelist links、そしてタイプ分離の欠如により、攻撃者は UAF/overflow バグを任意のカーネルメモリ制御へエスカレートできました。

Heap Grooming / Feng Shui

The goal of heap grooming is to shape the heap layout so that when an attacker triggers an overflow or use-after-free, the target (victim) object sits right next to an attacker-controlled object.
That way, when memory corruption happens, the attacker can reliably overwrite the victim object with controlled data.

Steps:

1. Spray allocations (fill the holes)

• Over time, the kernel heap gets fragmented: some zones have holes where old objects were freed.
• The attacker first makes lots of dummy allocations to fill these gaps, so the heap becomes “packed” and predictable.

2. Force new pages

• Once the holes are filled, the next allocations must come from new pages added to the zone.
• Fresh pages mean objects will be clustered together, not scattered across old fragmented memory.
• This gives the attacker much better control of neighbors.

3. Place attacker objects

• The attacker now sprays again, creating lots of attacker-controlled objects in those new pages.
• These objects are predictable in size and placement (since they all belong to the same zone).

4. Free a controlled object (make a gap)

• The attacker deliberately frees one of their own objects.
• This creates a “hole” in the heap, which the allocator will later reuse for the next allocation of that size.

5. Victim object lands in the hole

• The attacker triggers the kernel to allocate the victim object (the one they want to corrupt).
• Since the hole is the first available slot in the freelist, the victim is placed exactly where the attacker freed their object.

6. Overflow / UAF into victim

• Now the attacker has attacker-controlled objects around the victim.
• By overflowing from one of their own objects (or reusing a freed one), they can reliably overwrite the victim’s memory fields with chosen values.

Why it works:

• Zone allocator predictability: allocations of the same size always come from the same zone.
• Freelist behavior: new allocations reuse the most recently freed chunk first.
• Heap sprays: attacker fills memory with predictable content and controls layout.
• End result: attacker controls where the victim object lands and what data sits next to it.

Modern Kernel Heap (iOS 15+/A12+ SoCs)

Apple hardened the allocator and made heap grooming much harder:

1. From Classic kalloc to kalloc_type

• Before: a single kalloc.<size> zone existed for each size class (16, 32, 64, … 1280, etc.). Any object of that size was placed there → attacker objects could sit next to privileged kernel objects.
• Now:
• Kernel objects are allocated from typed zones (kalloc_type).
• Each type of object (e.g., ipc_port_t, task_t, OSString, OSData) has its own dedicated zone, even if they’re the same size.
• The mapping between object type ↔ zone is generated from the kalloc_type system at compile time.

An attacker can no longer guarantee that controlled data (OSData) ends up adjacent to sensitive kernel objects (task_t) of the same size.

2. Slabs and Per-CPU Caches

• The heap is divided into slabs (pages of memory carved into fixed-size chunks for that zone).
• Each zone has a per-CPU cache to reduce contention.
• Allocation path:

1. Try per-CPU cache.
2. If empty, pull from the global freelist.
3. If freelist is empty, allocate a new slab (one or more pages).

• Benefit: This decentralization makes heap sprays less deterministic, since allocations may be satisfied from different CPUs’ caches.

3. Randomization inside zones

• Within a zone, freed elements are not handed back in simple FIFO/LIFO order.
• Modern XNU uses encoded freelist pointers (safe-linking like Linux, introduced ~iOS 14).
• Each freelist pointer is XOR-encoded with a per-zone secret cookie.
• This prevents attackers from forging a fake freelist pointer if they gain a write primitive.
• Some allocations are randomized in their placement within a slab, so spraying doesn’t guarantee adjacency.

4. Guarded Allocations

• Certain critical kernel objects (e.g., credentials, task structures) are allocated in guarded zones.
• These zones insert guard pages (unmapped memory) between slabs or use redzones around objects.
• Any overflow into the guard page triggers a fault → immediate panic instead of silent corruption.

5. Page Protection Layer (PPL) and SPTM

• Even if you control a freed object, you can’t modify all of kernel memory:
• PPL (Page Protection Layer) enforces that certain regions (e.g., code signing data, entitlements) are read-only even to the kernel itself.
• On A15/M2+ devices, this role is replaced/enhanced by SPTM (Secure Page Table Monitor) + TXM (Trusted Execution Monitor).
• These hardware-enforced layers mean attackers can’t escalate from a single heap corruption to arbitrary patching of critical security structures.
• (Added / Enhanced): also, PAC (Pointer Authentication Codes) is used in the kernel to protect pointers (especially function pointers, vtables) so that forging or corrupting them becomes harder.
• (Added / Enhanced): zones may enforce zone_require / zone enforcement, i.e. that an object freed can only be returned through its correct typed zone; invalid cross-zone frees may panic or be rejected. (Apple alludes to this in their memory safety posts)

6. Large Allocations

• Not all allocations go through kalloc_type.
• Very large requests (above ~16 KB) bypass typed zones and are served directly from kernel VM (kmem) via page allocations.
• These are less predictable, but also less exploitable, since they don’t share slabs with other objects.

7. Allocation Patterns Attackers Target

Even with these protections, attackers still look for:

• Reference count objects: if you can tamper with retain/release counters, you may cause use-after-free.
• Objects with function pointers (vtables): corrupting one still yields control flow.
• Shared memory objects (IOSurface, Mach ports): these are still attack targets because they bridge user ↔ kernel.

But — unlike before — you can’t just spray OSData and expect it to neighbor a task_t. You need type-specific bugs or info leaks to succeed.

Example: Allocation Flow in Modern Heap

Suppose userspace calls into IOKit to allocate an OSData object:

1. Type lookup → OSData maps to kalloc_type_osdata zone (size 64 bytes).
2. Check per-CPU cache for free elements.

• If found → return one.
• If empty → go to global freelist.
• If freelist empty → allocate a new slab (page of 4KB → 64 chunks of 64 bytes).

3. Return chunk to caller.

Freelist pointer protection:

• Each freed chunk stores the address of the next free chunk, but encoded with a secret key.
• Overwriting that field with attacker data won’t work unless you know the key.

Comparison Table

Modern Userland Heap (iOS, macOS — type-aware / xzone malloc)

In recent Apple OS versions (especially iOS 17+), Apple introduced a more secure userland allocator, xzone malloc (XZM). This is the user-space analog to the kernel’s kalloc_type, applying type awareness, metadata isolation, and memory tagging safeguards.

Goals & Design Principles

• Type segregation / type awareness: group allocations by type or usage (pointer vs data) to prevent type confusion and cross-type reuse.
• Metadata isolation: separate heap metadata (e.g. free lists, size/state bits) from object payloads so that out-of-bounds writes are less likely to corrupt metadata.
• Guard pages / redzones: insert unmapped pages or padding around allocations to catch overflows.
• Memory tagging (EMTE / MIE): work in conjunction with hardware tagging to detect use-after-free, out-of-bounds, and invalid accesses.
• Scalable performance: maintain low overhead, avoid excessive fragmentation, and support many allocations per second with low latency.

Architecture & Components

Below are the main elements in the xzone allocator:

Segment Groups & Zones

• Segment groups partition the address space by usage categories: e.g. data, pointer_xzones, data_large, pointer_large.
• Each segment group contains segments (VM ranges) that host allocations for that category.
• Associated with each segment is a metadata slab (separate VM area) that stores metadata (e.g. free/used bits, size/classes) for that segment. This out-of-line (OOL) metadata ensures that metadata is not intermingled with object payloads, mitigating corruption from overflows.
• Segments are carved into chunks (slices) which in turn are subdivided into blocks (allocation units). A chunk is tied to a specific size class and segment group (i.e. all blocks in a chunk share the same size & category).
• For small / medium allocations, it will use fixed-size chunks; for large/huges, it may map separately.

Chunks & Blocks

• A chunk is a region (often several pages) dedicated to allocations of one size class within a group.
• Inside a chunk, blocks are slots available for allocations. Freed blocks are tracked via the metadata slab — e.g. via bitmaps or free lists stored out-of-line.
• Between chunks (or within), guard slices / guard pages may be inserted (e.g. unmapped slices) to catch out-of-bounds writes.

Type / Type ID

• Every allocation site (or call to malloc, calloc, etc.) is associated with a type identifier (a malloc_type_id_t) which encodes what kind of object is being allocated. That type ID is passed to the allocator, which uses it to select which zone / segment to serve the allocation.
• Because of this, even if two allocations have the same size, they may go into entirely different zones if their types differ.
• In early iOS 17 versions, not all APIs (e.g. CFAllocator) were fully type-aware; Apple addressed some of those weaknesses in iOS 18.

Allocation & Freeing Workflow

Here is a high-level flow of how allocation and deallocation operate in xzone:

1. malloc / calloc / realloc / typed alloc is invoked with a size and type ID.
2. The allocator uses the type ID to pick the correct segment group / zone.
3. Within that zone/segment, it seeks a chunk that has free blocks of the requested size.

• It may consult local caches / per-thread pools or free block lists from metadata.
• If no free block is available, it may allocate a new chunk in that zone.

4. The metadata slab is updated (free bit cleared, bookkeeping).
5. If memory tagging (EMTE) is in play, the returned block gets a tag assigned, and metadata is updated to reflect its “live” state.
6. When free() is called:

• The block is marked as freed in metadata (via OOL slab).
• The block may be placed into a free list or pooled for reuse.
• Optionally, block contents may be cleared or poisoned to reduce data leaks or use-after-free exploitation.
• The hardware tag associated with the block may be invalidated or re-tagged.
• If an entire chunk becomes free (all blocks freed), the allocator may reclaim that chunk (unmap it or return to OS) under memory pressure.

Security Features & Hardening

These are the defenses built into modern userland xzone:

Interaction with Memory Integrity Enforcement (MIE / EMTE)

• Apple’s MIE (Memory Integrity Enforcement) is the hardware + OS framework that brings Enhanced Memory Tagging Extension (EMTE) into always-on, synchronous mode across major attack surfaces.
• xzone allocator is a fundamental foundation of MIE in user space: allocations done via xzone get tags, and accesses are checked by hardware.
• In MIE, the allocator, tag assignment, metadata management, and tag confidentiality enforcement are integrated to ensure that memory errors (e.g. stale reads, OOB, UAF) are caught immediately, not exploited later.

If you like, I can also generate a cheat-sheet or diagram of xzone internals for your book. Do you want me to do that next? ::contentReference[oai:20]{index=20}

(Old) Physical Use-After-Free via IOSurface

ios Physical UAF - IOSurface

Ghidra Install BinDiff

Download BinDiff DMG from https://www.zynamics.com/bindiff/manual and install it.

Open Ghidra with ghidraRun and go to File --> Install Extensions, press the add button and select the path /Applications/BinDiff/Extra/Ghidra/BinExport and click OK and isntall it even if there is a version mismatch.

Using BinDiff with Kernel versions

1. Go to the page https://ipsw.me/ and download the iOS versions you want to diff. These will be .ipsw files.
2. Decompress until you get the bin format of the kernelcache of both .ipsw files. You have information on how to do this on:

macOS Kernel Extensions & Kernelcache

3. Open Ghidra with ghidraRun, create a new project and load the kernelcaches.
4. Open each kernelcache so they are automatically analyzed by Ghidra.
5. Then, on the project Window of Ghidra, right click each kernelcache, select Export, select format Binary BinExport (v2) for BinDiff and export them.
6. Open BinDiff, create a new workspace and add a new diff indicating as primary file the kernelcache that contains the vulnerability and as secondary file the patched kernelcache.

Finding the right XNU version

If you want to check for vulnerabilities in a specific version of iOS, you can check which XNU release version the iOS version uses at [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).

For example, the versions 15.1 RC, 15.1 and 15.1.1 use the version Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006.

iMessage/Media Parser Zero-Click Chains

Imessage Media Parser Zero Click Coreaudio Pac Bypass