arm64e.x1：Apple 的檢查式指標運算切片

arm64e.x1 是什麼？ 這是一個 CPU 子類型為 12 的全新 Mach-O 切片，Apple 在 9 月 11 日的 iOS 27 RC 發行說明中，只用一段話介紹了它：在搭載 A20 Pro 或更新晶片的 iPhone、搭載 M6 或更新晶片的 Mac，以及搭載 S11 或更新晶片的 Apple Watch 上，它「導入額外的硬體安全與效能指令，其中包括用於強化 MIE 保護的 CPA2」。¹ 在這個切片裡，Apple clang 21 會把一般的指標運算編譯成 Arm 的 addpt 指令；一旦運算溢位到指標的最高位元組，也就是記憶體標籤所在之處，這道指令便會汙染（poison）該指標，而不是任由計算結果呈現出一個硬體願意接受的標籤。Xcode 27 以一項建置設定加入這個切片，執行階段的強制則由 Enhanced Security 授權以及其下的兩項授權把關。²³

重點摘要： 我的監看程式在上午 10:01（PT）那次檢查時，這段話已經進入 iOS 與 watchOS 27 RC 的發行說明，到上午 11:12 也進入了 macOS 的說明；其中的「Learn more」連結指向 Apple 內部的草稿主機，而公開的 Enhanced Security 文章至今仍未提到這個切片。¹⁴⁵ Xcode 27 RC 則早已備妥一切：子類型常數、以 +cpa 鎖定 apple-a20 的編譯器、建置設定，以及一份把四個開關寫得清清楚楚的參考文件。⁶²⁷³ 已發表的硬體包括 iPhone 18 Pro 與 iPhone Duo（A20 Pro）、M6 版 Mac mini、Apple Watch Series 12 與 Ultra 4（S11）；iPhone 17 系列不在名單上。¹⁹ 三個切片都要建置，指標驗證保持開啟，並且要有心理準備：當機的位置往往離出問題的那次運算很遠。

更新，9 月 17 日：macOS 26.6 上的 App Store 上傳阻礙

在我 9 月 16 日與 9 月 17 日兩次抓取文件 JSON 之間，Apple 在 Xcode 27 發行說明的 Enhanced Security 區塊新增了一則 Known Issue：「Apps with Hardware-Checked Pointer Arithmetic Slice feature enabled cannot be uploaded to the App Store on macOS Tahoe 26.6 with Xcode automatic signing enabled.」（啟用 Hardware-Checked Pointer Arithmetic Slice 功能的 App，在 macOS Tahoe 26.6 上開啟 Xcode 自動簽署時，無法上傳到 App Store。）Apple 給的因應方式是：「Distribute with macOS 27 and Xcode 27 or use manual signing.」（改用 macOS 27 與 Xcode 27 發布，或改用手動簽署。）¹⁴ 所以，帶有 arm64e.x1 切片的建置，在 Xcode 27 所支援的最低主機上多了一項發布成本：一台仍停留在 Tahoe 26.6，也就是 Xcode 27 所要求最低版本的 Mac，無法以自動簽署上傳那個建置。依 Apple 的說明，手動簽署或改用 macOS 27 主機就能解決；我沒有 macOS 27 的機器，兩條路都還沒有試過。¹⁴

出現了什麼，又出現在哪裡

iOS 與 iPadOS 27 RC 的發行說明多了一個標題為 Hardware Security 的段落區塊，那段文字就放在它的 New Features 子標題之下。全文如下：

arm64e.x1 導入額外的硬體安全與效能指令，其中包括用於強化 MIE 保護的 CPA2。支援 arm64e.x1 的裝置包括搭載 A20 Pro 或更新晶片的 iPhone 機型、搭載 M6 或更新晶片的 Mac 電腦，以及搭載 S11 或更新晶片的 Apple Watch 機型。您可以在 Xcode 中透過 enhanced security 面板與一項建置設定使用 arm64e.x1 與 CPA2。詳情請參閱 Enhanced Security 文章。(152103975)¹

watchOS 27 RC 的發行說明在同一次檢查中也多了同樣一段。macOS 27 RC 的說明在上午 10:02（PT）時還沒有，儘管那段話本身就把搭載 M6 或更新晶片的 Mac 列了進去；到了上午 11:12（PT），macOS 的說明也帶上了它，連結一模一樣。⁴ 我的監看程式每隔幾分鐘抓取這三個頁面，而三者自 9 月 9 日以來都不曾變動。

這段話裡有兩處細節值得留意。其一，「Learn more」連結並未通往公開文件。頁面資料指出的目標位址是 https://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-app，這台主機在 Apple 之外根本無法解析。¹ 其二，路徑與之相符的公開文章為你的 App 啟用 enhanced security 截至上午 10:40（PT），既沒提 arm64e.x1，也沒提 CPA2；它記錄的仍舊是這項能力的各項建置設定，從 ENABLE_POINTER_AUTHENTICATION 一路到 CLANG_ENABLE_STACK_ZERO_INIT。⁵

自 9 月 9 日 RC 推出以來，Xcode 27 RC 的發行說明就在 Enhanced Security 之下帶著一則對應條目，而真正點明機制名稱的正是它：

arm64e.x1，也就是 Hardware-Checked Pointer Arithmetic 切片，透過檢查是否溢位至記憶體標籤來落實 Check for Overflow of Pointer Arithmetic 授權，在 Memory Integrity Enforcement 之上再提供一層保護。(152104701)¹⁰

這個切片並不是什麼祕密。9 月 9 日下午 1:40（PT），以 Longhorn 之名發文的研究者寫道：「Apple M6/A20 搭載 FEAT_CPA2——檢查式指標運算——而且有一種為它準備的新執行檔類型」，並引用了一句話；後來證實那句話出自 Xcode 內部的一份文件。¹¹ iOS 與 watchOS 的發行說明，兩天後才跟上。

從 SDK 與編譯器看這個切片

Xcode 27.0（建置版本 27A266a）中的 iOS SDK 在 mach/machine.h 裡定義了這個子類型：

#define CPU_SUBTYPE_ARM64E              ((cpu_subtype_t) 2)
/* The non-e x1 is defined in other tooling, but it's otherwise unused. */
#define CPU_SUBTYPE_ARM64_X1            ((cpu_subtype_t) 3)
#define CPU_SUBTYPE_ARM64E_X1           ((cpu_subtype_t) 12)

輔助巨集上方的註解交代了這套命名走向何處：「目前的 PAC 切片包括 ARM64E 與 ARM64E_X1。未來的切片_可能_沿用這項慣例。」⁶

這一版 Xcode 隨附的編譯器 Apple clang 21.0.0（clang-2100.3.34.2）接受 -arch arm64e.x1，並把它當成另一顆 CPU 看待。加上 -###，它回報 -target-cpu apple-a20，功能清單中含有 +cpa、+mte、+pauth、+pauth-lr 與 +fpac。單純的 -arch arm64e 回報的則是 -target-cpu apple-a12，沒有 +cpa。² 目的檔的標頭把子類型記為 E.X1，而 lipo -info 把這個架構稱作 arm64e.x1。

差別只在一個助憶符號。以一個把索引加到指標上的函式為例：

int *g(int *p, long i) { return p + i; }

以 -O2 為 arm64e 建置，函式主體就是一道 add 加一道返回；為 arm64e.x1 建置，這道 add 就變成 addpt：

-arch arm64e:
    add   x0, x0, x1, lsl #2
    ret

-arch arm64e.x1:
    addpt x0, x0, x1, lsl #2
    ret

這次建置不需要任何旗標；選定架構，檢查式運算就開啟了。² 旗標的存在是為了反方向的需求，以及為了其他切片。clang 的說明列出 -fchecked-pointer-arithmetic，描述為「啟用檢查式指標運算，必要時使用軟體序列」，另外還有 -fno-checked-pointer-arithmetic。² 加上這個旗標後，一般的 arm64e 與 arm64 會得到一段軟體序列：一道普通的 add、一次基底與結果的互斥或、一次針對高 10 個位元 [63:54] 與 0xffc0000000000000 的比對，若兩者不符，再以一道 movk 把 0xc8a2 寫進指標的高 16 個位元，使它成為非正規（non-canonical）位址。若改用 -fno-checked-pointer-arithmetic，arm64e.x1 也會退回普通的 add。²

CPA2 檢查的是什麼

Apple 在 Xcode 27 內部為它的編碼助理附上了一份參考文件，這份文件把這項檢查解釋得比發行說明清楚得多。開頭第一句是：「檢查式指標運算讓支援 FEAT_CPA2 擴充的硬體能夠偵測到指標計算何時從位址位元溢位到指標的高位元。」文件也說明了最高位元組為何重要：「正是溢位到這些位元，才讓運算得以從一個物件一路走進另一個物件，同時仍呈現出硬體願意接受的標籤。」接著是：「偵測發生在兩處：明確的運算會汙染自己的結果，而每一次 load 與 store 都會檢查它在定址模式中所做的那次加法。」³

比較的對象是兩個最高位元組。「這項檢查會把結果的最高位元組，也就是位元 [63:56]，與基底運算元的最高位元組相比較。啟用 MTE 時，這個位元組會在位元 [59:56] 中帶著 4 位元的 Memory Tagging Extension（MTE）標籤。」未通過檢查的指標會被硬體汙染，而上面那段軟體序列模仿的正是這種汙染：「被汙染的指標刻意成為非正規位址，因此下一次解參考會觸發第 0 層轉譯錯誤，並以 EXC_ARM_CPA_FAIL（0x108）送出，ESR 為 0x92000004（讀取）或 0x92000044（寫入）。」³

指令本身來自 Arm。LLVM 中加入組譯器支援的修補程式於 2023 年 11 月 30 日合併，它把 Checked Pointer Arithmetic Extension（FEAT_CPA）描述為隨 Armv9.5-A 架構一同發表的特性，並加入純量指令 ADDPT、SUBPT、MADDPT、MSUBPT 以及向量形式。¹² Apple 的發行說明與參考文件說的都是 CPA2，也就是硬體必須支援的那個致能擴充，其定義即如上所引。³

Apple 那段話裡的「MIE」指的是 Memory Integrity Enforcement。Apple 安全團隊在 2025 年 9 月 9 日發表它時，稱之為「我們為 Apple 平台打造的全面記憶體安全防禦」，並說它「直接內建於所有 iPhone 17 與 iPhone Air 機型的 Apple 硬體與軟體之中」，基礎則是 Apple 與 Arm 共同開發的 Enhanced Memory Tagging Extension（EMTE）。⁸ 那篇文章告訴開發者，他們可以「使用 Xcode 中的 Enhanced Security 設定，為自己的 App 開始測試這項強大的保護，包括在支援的硬體上測試 EMTE」。⁸ CPA2 補上的是標籤機制中一個具體的缺口。標籤機制比對指標最高位元組裡的標籤與所存取記憶體的標籤，因此，一個只是越界進入相鄰配置、卻沒有驚動最高位元組的指標，正是標籤機制管得到的情形：標籤不符，存取就錯誤。標籤機制看不見的，是溢位到最高位元組的那類運算，因為它能「製造出一個標籤與另一塊配置相符的指標」，而依參考文件的說法，「沒有這項檢查，這種溢位正是攻擊者擊破標籤機制的手段」。³

Xcode 27 裡的四個開關

參考文件說得很直白：「App target 上必須啟用四樣東西。少一樣就沒有保護。」³ 它們是：

1. 建置設定 ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES，在 Build Settings 的 Security 分類下顯示為「Enable Hardware-Checked Pointer Arithmetic Slice」。它確實存在於 Xcode 27 RC 的建置系統規格中。³⁷
2. Enhanced Security 授權 com.apple.security.hardened-process，透過 Signing & Capabilities 中的對應 capability 加入。
3. 硬體記憶體標籤 com.apple.security.hardened-process.checked-allocations，也就是 Memory Safety 裡的「Enable Hardware Memory Tagging」選項。
4. 強制授權 com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow，也就是「Enforce Checking for Overflow of Pointer Arithmetic」選項。

「第 4 列是第 3 列的子選項，第 3 列又是第 2 列的子選項。」³ 之所以非要啟用標籤機制不可，是因為最高位元組裡得裝著值得比對的東西。

那項建置設定只做一件事：它「把 arm64e.x1 附加到 ARCHS_STANDARD」。而這件事本身另有前提：「如果 ARCHS 被覆寫成並非以 ARCHS_STANDARD 為基礎的值，這項設定就不會生效。」手寫授權檔案還得多加一個鍵：「第 2 列還需要 com.apple.security.hardened-process.enhanced-security-version-string = 2；加入 capability 時 Xcode 會寫入這個鍵，所以如果你直接編輯授權檔案，就得自己寫上去。」文件針對 iOS target 實測出來的那張表，值得記牢。³

請採用最後一列。若開啟切片卻關掉指標驗證，不支援 CPA2 的裝置會退回純 arm64，連原本可享有的指標驗證也一併失去。³ 驗證方式就照文件的做法：

lipo -archs MyApp.app/MyApp        # expect: arm64 arm64e arm64e.x1

同一份文件裡還有三項事實，應該與這張表擺在一起。「__arm64e_x1__ 是預先定義的巨集，供那些必須為 arm64e.x1 切片作不同編譯的程式碼使用。」模擬器則什麼都不必做：「模擬器 SDK 不定義 arm64e.x1 架構，因此建置系統會把它從模擬器建置的有效架構中剔除，做法與處理 arm64e 完全相同。」Apple 把執行階段的額外負擔形容為很低，代價落在體積上：「代價是二進位檔的大小：多出第三個切片。」³ 函式庫與框架只需要那項建置設定；授權是系統以主執行檔為起點、按行程授予的。而且，就算某個函式庫只帶 arm64e，被一個開啟強制的 App 載入時照樣受惠：「該函式庫中的 load/store 指令仍會受到檢查。」³

至於程式碼改動：「通常不需要。編譯器會在 arm64e.x1 切片中產生檢查式指令，只要『How to Enable』中的那些授權就位，硬體就會強制執行。」³ 例外是那些運算會驚動最高位元組的寫法，文件一一列出：兩塊不同配置之間的指標差值、越過物件尾端仍繼續帶著的位移量、以 NULL 為基底的運算，以及以整數型別參與運算的指標。關於穩定性的提醒只有一句：「帶有潛在指標運算錯誤的程式碼會當機。」文件還警告，執行汙染的那道指令與發生錯誤的那次解參考「可能位於不同的函式、不同的檔案或不同的函式庫中」。³ 如果某個 target 設了強制授權卻不建置該切片，Xcode 會在建置時發出警告；文件稱這道警告是「設定不完整的唯一訊號」。³

哪些硬體支援

Apple 列出的是晶片，而 9 月的一連串發表把晶片對應到了產品。A20 Pro 用於 iPhone 18 Pro 與 iPhone 18 Pro Max，「全都由 A20 Pro 驅動」，也用於 iPhone Duo，「由全新的 A20 Pro 驅動」。⁹ S11 則是 Apple Watch Series 12 與 Apple Watch Ultra 4 的晶片。⁹ Apple 於 8 月 25 日在標題為「Apple 推出搭載全新 M6 與 M5 Pro、效能更強的 Mac mini」的新聞稿中公布了 M6。⁹ 發表不等於到手：依 Apple 的時程，iPhone 18 Pro 與新款 Apple Watch 於 9 月 18 日上市，Mac mini 於 9 月 22 日上市，iPhone Duo 則要等到 10 月 23 日。⁹ 參考文件自己的平台清單只寫了 A20 Pro 上的 iOS 與 S11 上的 watchOS，對發行說明所納入的 Mac 隻字未提。³ iPhone 17 與 iPhone Air 所用的 A19 與 A19 Pro 晶片能執行 Memory Integrity Enforcement，卻不在 arm64e.x1 名單之列；因此，若某次建置為 arm64e 打開了那個旗標，這些手機上跑的會是軟體序列，而不是 addpt。¹⁸

對於正在為 iPhone Duo 開發的人來說，這個切片是第一項不必等 iOS 27.1 SDK 的 Duo 相關工具鏈變動。它今天就在 Xcode 27 RC 裡，而搭載 A20 Pro 的 Duo，從上市第一天起就列在強制名單上。

換作是我會怎麼做

對於已經採用 Enhanced Security 的 App，把表格最後一列打開，並且先在分支上加入強制授權。等硬體到手，就把每一次 EXC_ARM_CPA_FAIL 都當成一份關於指標運算的錯誤回報，去找汙染發生的位置，而不是當機發生的位置。arm64e 上的那個旗標就別碰了：軟體序列會在每一次指標加法上多花指令，而更值得押注的是切片本身。在 Apple 把發行說明所指向的那篇文章公開之前，Xcode 內部的這份參考文件，就是它已經交付出來最完整的說明。

重點整理

給 iOS 與 macOS 工程師： - arm64e.x1 是 Mach-O 的第 12 號 CPU 子類型；clang 為它以 +cpa 鎖定 apple-a20，並把指標運算編譯成 addpt。 - 強制需要四個開關：切片建置設定、Enhanced Security、硬體記憶體標籤，以及溢位授權。建置目標為 arm64 arm64e arm64e.x1。

給安全與平台負責人： - 在強制之下，檢查式運算指令會把結果的最高位元組與基底的最高位元組相比較，不符即汙染，藉此堵住繞過記憶體標籤的運算路徑；load 與 store 的位址計算同樣會受到檢查，即使是被強制中的 App 所載入的一般 arm64e 函式庫也一樣。 - 已發表的相容硬體包括 A20 Pro（iPhone 18 Pro、iPhone Duo）、M6（Mac mini）、S11（Watch Series 12 與 Ultra 4）。iPhone 17 不在名單上；這些裝置自 9 月 18 日起陸續上市。

給關注 Apple 文件動向的人： - 發行說明裡的那段話連向內部草稿主機，公開文章則明顯落後；目前完整的來源，是 Xcode 27 RC 隨附的參考文件。

常見問題

arm64e.x1 會取代 arm64e 嗎？

不會。Apple 自己實測的表格把建議組態列為 arm64 arm64e arm64e.x1，而參考文件指出，一個只建置 x1 切片、卻關閉指標驗證的 target，根本不會帶任何 arm64e 切片，於是較舊的裝置會失去指標驗證。³

我需要改程式碼嗎？

多半不必。編譯器會產生檢查式指令，只要授權就位，硬體就會強制執行。那些指標運算會驚動最高位元組的程式碼——例如指向不同配置的兩個指標之間的差值、越過物件尾端很遠仍繼續帶著的位移量，或是以 NULL 為基底的運算——在強制之下就會出錯，而這正是它的用意所在；Apple 的參考文件說這類程式碼「會當機」。³

哪些裝置會強制執行？

依發行說明所述：搭載 A20 Pro 或更新晶片的 iPhone、搭載 M6 或更新晶片的 Mac，以及搭載 S11 或更新晶片的 Apple Watch。¹ 在其他裝置上，載入器不會選用這個切片，一切照舊。

CPA2 和 Arm 的 FEAT_CPA 是同一回事嗎？

不是。Arm 的特性名錄把 FEAT_CPA 列為「Instruction-only Checked Pointer Arithmetic」，把 FEAT_CPA2 列為「Checked Pointer Arithmetic」：前者提供 clang 會產生的 ADDPT 系列指令，後者才是檢查本身所需的硬體支援。¹³¹² Apple 指名的要求是 CPA2，其參考文件談到 A20 Pro 與 S11 時寫道：「兩款晶片都支援 FEAT_CPA2，而 arm64e.x1 切片正是以它為目標。」³

資料來源