開機流程的變化：SPTM 的加入#

Apple 晶片的開機流程與任何常見的 Arm 晶片都不同，採用自家封閉原始碼的 iBoot 韌體，而不是常見的 U-Boot 或者 UEFI。這也使得讓 Linux 核心開機也變得困難，因爲 iBoot 從實作上就被設定爲僅能載入符合 Apple 規範格式與簽章的 kernelcache（Mach-O 格式）。雖然 macOS 也使用設備樹來描述硬體，但 macOS 採用 Apple 自家的「客製化」設備樹 ADT (Apple Device Tree)，與 Linux 的 DTB 不相容. 不過 Asahi Linux 社群爲了解決這一個難題而開發了 m1n1 開機載入器，能夠在開機時自動存取 ADT 設備樹，並轉製成被 Linux 支援的 DTB，這樣就可以啓動 Linux 核心。

隨着 M4 晶片的發佈（還有 A18 Pro 晶片），一種叫 「SPTM (Secure page table monitor，安全頁表監視)」的機制被引入。SPTM 執行在較高的硬體等級（Apple 自定義的 GL2，類似 Arm 的 EL2 等級），必須要經由 iBoot 開機載入後才可以執行其他作業系統，目前沒有辦法 bypass 掉。而之前的 M1, M2, M3 晶片則採用內建於 XNU 核心快取的「PPL（Page Protection Layer，頁表保護）」同樣執行在 GL2 等級，但是 PPL 沒有專門的韌體。SPTM 在 iBoot 啟動流程中被初始化，並作為系統安全執行環境的一部分存在，位於專門的安全空間，受到 SPRR 保護。在這種環境下，SPTM 中的程式碼只能在 GL2 執行，因此任何存在於 EL1 的漏洞不會影響頁表。
不過，macOS 在 A18 Pro 晶片上的開機流程和M系列晶片平臺大致相同，加載 PPL¹，SPTM 只會被 iOS 核心加載。據此就會有兩種開機方案：要嘛加載一個自訂的 macOS 核心快取，這樣 iBoot 大概不會載入 SPTM。因爲 Asahi Linux 專案早就逆向了 PPL 的組建，所以比較容易開機，變磚風險也相對低；要嘛加載自訂 iOS 核心快取打開 SPTM，移植難度大，但是可以爲後期改善A18 Pro 晶片 Linux 支援做準備。

Apple 風格的「Secure Launch」：XNU Shim#

既然 SPTM 的啟用與否取決於所載入的核心快取類型（如 iOS kernelcache），那就可以開發一種開機載入器，把載入器和 XNU 核心快取縫在一起，開機後 iBoot 讀取自訂的核心快取完成打開 SPTM，之後載入 Linux loader 就可以啓動 Linux 核心了。
這也就是 XNU Shim 要實現的，藉由 Mach-O 啓動協定，其核心思路並不是取代 boot chain，而是「嵌入」到 XNU 的啟動流程中。在 iBoot 載入自訂 kernelcache 後，系統會正常初始化 XNU，包括 MMU、CPU 狀態以及 PPL（或 SPTM）等安全機制。

SecureROM
  └─► iBoot stage 1 (位於 Nor Flash 快閃記憶體)
        └─► iBoot stage 2 (位於固態硬碟, APFS Preboot)
              └─► kernelcache (非 Apple 的「低安全性」簽章，簡化的自訂 XNU 核心和快取)
                    ├─► [XNU startup] cpu_machine_init → SPTM init calls
                    ├─► [XNU startup] arm_init → 負責 MMU 初始化，而 SPTM 僅對頁表操作進行約束與監控
                    └─► [SHIM INTERCEPT] → Linux loader → Linux 核心啓動

這種特製的 shim 會讓 iBoot 認爲自己正在載入合規的 macOS 核心。在 XNU 核心初始化流程中 hook「IOPE（IOPlatformExpert::start()）階段」（或者是其他合適的階段），此時 SPTM 和其他底層機制已經初始化。並使用 SPTM API 建立 Linux 核心啓動必須的記憶體空間，準備 initramfs，DTB 之類，關閉 SPTM Watchdog，完成跳轉 Linux 核心。概念上類似於高通 「Secure Launch」 在受控環境中啟動 OS，但 Apple 並未提供正式的3方「secure launch」 機制，XNU shim 本質上屬於啟動後接管（post-boot hijack），而非受支援的安全啟動模式。

A18/M4 晶片上自訂的 GXF 側域模型（GXF lateral domain,GLs）：抽象層級而非 ARM EL 映射#

Apple 在 A18/M4 晶片上建立了一套與 ARM EL 模型概念上相似，但並不完全對應的執行域 (execution domain) 架構。這些 GXF（GL0–GL2）層級主要透過 SPRR 機制強制執行記憶體存取權限，而非直接對應 ARM 異常層級。SPRR 是用於強制執行記憶體存取屬性的硬體機制，負責限制不同執行域對 page table 權限的修改能力。
吶，下面的表格就可以清楚地展示 GXF Level 和 ARM ELs 層級之間的關係²:

註：斜體字 表示沒有與 ELs 異常層級抽象對應的 GXF 側迴區等級，或者這一等級目前在公開研究中較少觀察到（甚至沒有）實際使用。

NOTE

• GL2（SPTM 所在的安全監控層）在功能上類似於高權限控制平面，但並不等同於 EL2 hypervisor，而是 Apple 自定義的記憶體安全執行層。
• genter/ gexit 匯編函式是進入與退出 SPTM 管理上下文的介面，而非 ARM EL 層級之間的直接轉換機制。
• SPRR 則負責在硬體層級強制執行 page table 存取屬性，限制不同執行域對記憶體的讀寫與執行權限。
• 針對每次頁表變更，作業系統核心會透過 genter → GL2 → gexit的流程呼叫 SPTM 完成頁表變更。
• 顯而易見，Apple 晶片採用 GXF 和常見的 EL 模型，用於保証記憶體安全，讓每個環節的程式執行儘量減少被攻擊可能。

這是根據表格繪製的對比圖，便於大家理解：

關鍵寄存器：GXF / SPRR 控制面的實際語義#

在經過粗略檢視 m1n1 原始碼之後，找到了有關 GXF 的「關鍵 CPU 寄存器」，³這些寄存器位於 EL1 可訪問空間，但實際影響 GL2 行為，本質上是一種「受控升權接口（controlled privilege escalation interface）」:

WARNING

下面講述的寄存器變數與實作基於硬體逆向探索得到，可能存在錯誤。在社群文檔更新之前，本段僅提供參考。

write_sysreg(SYS_IMP_APL_GXF_ENTER_EL1, arg_struct);

// 首先執行 gxf_init 進行 GXF 環境準備（此函式省略），SPRR 會早於 GXF 被開啓。

gxf_enter: 
    genter
    ret

_gxf_setup:           // GL2 初始化
    mov sp, x5
    ldr x1, =_gxf_vectors
    ldr x2, =_gxf_exc_sync
    ldr x3, =_gxf_entry
    msr SYS_IMP_APL_VBAR_GL1, x1    // 設定 GL1 exception vector
    msr SYS_IMP_APL_GXF_ABORT_EL1, x2   // GXF 錯誤處理
    msr SYS_IMP_APL_GXF_ENTER_EL1, x3     // 下一次 genter() 的入口

    mrs x4, CurrentEL
    cmp x4, #8
    bne 1f

    msr SYS_IMP_APL_SP_GL12, x6
    msr SYS_IMP_APL_VBAR_GL12, x1
    msr SYS_IMP_APL_GXF_ABORT_EL12, x2
    msr SYS_IMP_APL_GXF_ENTER_EL12, x3

1:
    isb
    gexit

_gxf_entry:
    stp x29, x30, [sp, #-16]!
    stp x23, x24, [sp, #-16]!
    stp x21, x22, [sp, #-16]!
    stp x19, x20, [sp, #-16]!

    // these registers would be overwritten by each exception happening in GL1/2
    // but we need them to gexit correctly again
    mrs x20, SYS_IMP_APL_SPSR_GL1
    mrs x21, SYS_IMP_APL_ASPSR_GL1
    mrs x22, SYS_IMP_APL_ESR_GL1    // 保存 GL1 狀態
    mrs x23, SYS_IMP_APL_ELR_GL1
    mrs x24, SYS_IMP_APL_FAR_GL1

    mov x5, x0
    mov x0, x1
    mov x1, x2
    mov x2, x3
    mov x3, x4

...
// 回復 GL1，使用 gexit 保証沒有洩露
    msr SYS_IMP_APL_SPSR_GL1, x20
    msr SYS_IMP_APL_ASPSR_GL1, x21
    msr SYS_IMP_APL_ESR_GL1, x22
    msr SYS_IMP_APL_ELR_GL1, x23
    msr SYS_IMP_APL_FAR_GL1, x24
...
    isb
    gexit

SPRR 權限表#

即使完成了相關寄存器設定，要讓 Linux 在 MacBook Neo 上穩定運行，XNU shim 仍需處理 SPRR（System Page Protection Register）所定義的記憶體權限約束，並在適當時機透過 SPTM 介面進行頁表操作。

在 asahi_neo 專案的逆向分析中，SPRR 權限表被觀察為一個 64-bit 寄存器，其內部由多個位元欄位組成，用於描述不同 page table permission class 對應的存取限制。這些欄位會被 SPTM 設定，用於限制較低權限 execution domain（如 EL1）建立不符合策略的記憶體映射。
asahi-neo 專案在探索 MacBook Neo 硬體的過程中得出了關於權限表的發現：

64-bit register encoding 16 4-bit nibbles, each mapping one page table permission class to separate EL/GL access rights. SPTM sets this table to prevent EL1 from creating writable+executable mappings in its own domain.

從行為上來看，SPRR 並不是單純的權限映射表，而是一種硬體層級的約束機制（constraint system），其作用是在記憶體存取與權限檢查過程中強制執行頁面屬性限制，確保核心無法繞過既定的安全策略（例如建立同時具備 writable 與 executable 權限的頁面）。

因此，在啟用 SPTM 的系統中，作業系統核心無法直接修改最終的頁表狀態，而必須透過受控的介面（如 genter 進入 SPTM 執行上下文）來完成相關操作。XNU shim 在此扮演的角色，是在 Linux 啟動前建立一組符合 SPRR 約束的記憶體佈局，並確保後續頁表操作能夠透過 SPTM 正確執行。

需要注意的是，SPRR 權限表的具體編碼與語義目前仍屬於逆向推測範疇，其行為主要來自觀察與實驗結果，而非官方文件定義。