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 一节新增了一条已知问题：”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。¹⁸ 对于 Mac，Xcode 27 放弃 Intel 介绍了这次发布中 ARCHS_STANDARD 的另一项变化：部署目标为 27.0 时去掉 x86_64。

对于正在为 iPhone Duo 做开发的人来说，这个切片是第一项无需等待 iOS 27.1 SDK 的、与 Duo 相关的工具链改动。它今天就在 Xcode 27 RC 里，而搭载 A20 Pro 的 Duo 从发售第一天起就位列强制执行名单。 为 iPhone Duo 准备您的 App带着一个真实的 App 走过了每一种姿态，直至提交审核。

换作是我会怎么做

对已经采用 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 切片正是以它为目标。”³

资料来源