arm64e.x1：Appleのチェック付きポインタ演算スライス

arm64e.x1とは何でしょうか。 CPUサブタイプ12を持つ新しいMach-Oスライスで、AppleはiOS 27 RCのリリースノートで9月11日にたった1段落だけ紹介しました。それによると、A20 Pro以降のチップを搭載したiPhone、M6以降のチップを搭載したMac、S11以降のチップを搭載したApple Watchにおいて、このスライスは「CPA2を含む、追加のハードウェアセキュリティおよびパフォーマンス命令を導入し、MIE保護をより強固にする」とされています。¹ このスライスでは、Apple clang 21が通常のポインタ演算をArmのaddpt命令にコンパイルします。この命令は、演算結果がポインタ最上位バイト（メモリタグが置かれる場所）へ桁あふれした場合にそのポインタを汚染（poison）し、ハードウェアが受け入れてしまうタグを演算結果に持たせません。Xcode 27はビルド設定1つでこのスライスを追加し、実行時の強制はEnhanced Securityエンタイトルメントと、その下に連なる2つのエンタイトルメントで制御します。²³

要点: この段落は、私のウォッチャーが午前10時01分（PT）に確認した時点でiOSとwatchOS 27 RCのノートに、午前11時12分にはmacOSのノートに届いていました。「Learn more」リンクの参照先はApple社内のドラフト用ホストであり、公開されているEnhanced Securityの記事にはまだこのスライスの記述がありません。¹⁴⁵ 一方、Xcode 27 RCはすでにすべてを備えています。サブタイプ定数、+cpa付きでapple-a20をターゲットするコンパイラ、ビルド設定、そして4つのスイッチを明記したリファレンス文書です。⁶²⁷³ 発表済みのハードウェアは、iPhone 18 ProとiPhone Duo（A20 Pro）、M6搭載Mac mini、Apple Watch Series 12とUltra 4（S11）。iPhone 17ファミリーはこのリストに入っていません。¹⁹ 3つのスライスをすべてビルドし、ポインタ認証は有効なままにしておきましょう。そして、原因となった演算からは遠く離れた場所でクラッシュが起きることを想定してください。

更新、9月17日：macOS 26.6上でのApp Storeアップロードのブロック

Appleは、私が9月16日と9月17日にドキュメントJSONを取得したあいだに、Xcode 27リリースノートのEnhanced Securityセクションに既知の問題を1つ追加しました。「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機能を有効にしたアプリは、Xcodeの自動署名が有効な状態では、macOS Tahoe 26.6上でApp Storeにアップロードできない）Appleが示す回避策はこうです。「Distribute with macOS 27 and Xcode 27 or use manual signing.」（macOS 27とXcode 27で配布するか、手動署名を使う）¹⁴ つまりarm64e.x1スライスを含むビルドには、Xcode 27が対応する最小のホスト上で配布コストが生じます。Xcode 27が要求する最小環境であるTahoe 26.6のままのMacでは、そのビルドを自動署名ではアップロードできないのです。Appleのノートによれば、手動署名かmacOS 27のホストならこれを回避できます。私にはmacOS 27のマシンがなく、どちらの道も試していません。¹⁴

何が、どこに現れたのか

iOSおよびiPadOS 27 RCのリリースノートに、Hardware Securityという見出しのセクションが追加され、その New Features サブ見出しの下にこの段落が置かれました。全文は次のとおりです。

arm64e.x1は、CPA2をはじめとする追加のハードウェアセキュリティおよびパフォーマンス命令を導入し、MIE保護をより強固にします。arm64e.x1をサポートするデバイスには、A20 Pro以降のチップを搭載したiPhone、M6以降のチップを搭載したMacコンピュータ、S11以降のチップを搭載したApple Watchが含まれます。arm64e.x1とCPA2には、Xcodeのenhanced securityペインとビルド設定からアクセスできます。詳しくはEnhanced Securityの記事をご覧ください。(152103975)¹

watchOS 27 RCのノートにも、同じ確認のタイミングで同じ段落が加わっていました。macOS 27 RCのノートには午前10時02分（PT）の時点で入っていませんでしたが、段落自体はM6以降のMacに言及しています。そして午前11時12分（PT）には、同じリンクを伴ってmacOSのノートにも載りました。⁴ 私のウォッチャーはこの3ページを数分おきに取得していますが、いずれも9月9日から変化がなかったのです。

この段落には注目すべき点が2つあります。まず「Learn more」リンクは公開ドキュメントを指していません。ページのデータが示すリンク先はhttps://docs.devpubs.apple.com/drafts/f16-dspector-161940504-rapid-isa-adoption-documentation/documentation/xcode/enabling-enhanced-security-for-your-appで、Apple社外からは名前解決できないホストです。¹ そして、同じパスに対応する公開記事アプリでenhanced securityを有効にするには、午前10時40分（PT）の時点でarm64e.x1にもCPA2にも触れられていません。記載されているのは相変わらず、ENABLE_POINTER_AUTHENTICATIONからCLANG_ENABLE_STACK_ZERO_INITに至るこの機能のビルド設定だけです。⁵

Xcode 27 RCのリリースノートには、RCが公開された9月9日から 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のノートが追いついたのは、その2日後でした。

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と呼びます。

違いはニーモニック1つです。ポインタにインデックスを加算する関数を例に取りましょう。

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

arm64e向けに-O2でビルドすると、本体はadd 1つとリターンだけです。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と照合するテスト、そして食い違った場合にポインタ上位16ビットへ0xc8a2を書き込むmovkです。これによりポインタは非正規（non-canonical）になります。-fno-checked-pointer-arithmeticを付けると、arm64e.x1でも素のaddに戻ります。²

CPA2は何を検査するのか

AppleはXcode 27の内部に、コーディングアシスタント向けのリファレンス文書を同梱しています。この検査については、リリースノートよりもそちらのほうが的確に説明しています。冒頭の一文はこうです。「チェック付きポインタ演算は、FEAT_CPA2拡張をサポートするハードウェアに、ポインタ演算がアドレスビットから桁あふれしてポインタ上位ビットへ達したことを検出させる。」なぜ最上位バイトが重要なのかも書かれています。「そこへ桁あふれさせることこそが、ハードウェアが受け入れるタグを保ったまま、あるオブジェクトから別のオブジェクトへ演算で歩いていくことを可能にする。」続けて、「検出は2か所で行われる。明示的な演算はその結果を汚染し、すべてのロードとストアはアドレッシングモードの一部として行う加算を検査する。」³

比較の対象は最上位バイト同士です。「この検査は、結果の最上位バイト、ビット［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設定を使えば、対応ハードウェア上のEMTEを含め、この強力な保護を自分のアプリで検証し始められる」と伝えていました。⁸ CPA2はタグ付けの特定の穴を1つ塞ぎます。タグ付けはポインタ最上位バイトのタグと、アクセス先メモリのタグとを突き合わせます。ですから、最上位バイトを乱さないまま隣接するアロケーションへ踏み込んだポインタは、タグ付けが扱える事例です。タグが食い違い、アクセスはフォルトします。タグ付けに見えないのは、最上位バイトへ桁あふれする演算のほうです。それは「別のアロケーションと一致するタグを持つポインタを作り出す」ことができ、リファレンス文書の言葉を借りれば「この検査がなければ、その桁あふれこそが攻撃者のタグ付け突破口になる」からです。³

Xcode 27の4つのスイッチ

リファレンス文書は率直です。「アプリターゲットでは4つを有効にしなければならない。1つでも欠ければ保護は成立しない。」³ その4つとは、

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でケイパビリティとして追加します。
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行目のサブオプションである。」³ タグ付けが必須なのは、比較する価値のあるものを最上位バイトが保持していなければならないからです。

ビルド設定がすることは1つだけ、「ARCHS_STANDARDにarm64e.x1を追記する」ことです。これには前提条件があります。「ARCHSがARCHS_STANDARDに基づかない値で上書きされている場合、この設定は効果を持たない。」また、エンタイトルメントファイルを手書きする場合はもう1つキーが必要です。「2行目にはcom.apple.security.hardened-process.enhanced-security-version-string = 2も必要である。ケイパビリティを追加すればXcodeがこのキーを書き込むので、エンタイトルメントファイルを直接編集するなら自分で書くこと。」iOSターゲットについて文書が実測した表は、覚えておく価値があります。³

使うべきは最後の行です。スライスを有効にしてポインタ認証を無効にすると、CPA2を持たないデバイスは素のarm64にフォールバックし、本来得られたはずのポインタ認証を失います。³ 結果は文書と同じ方法で確認しましょう。

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

同じ文書から、表の隣に置いておくべき事実がさらに3つあります。「__arm64e_x1__は定義済みマクロであり、arm64e.x1スライス向けに別のコンパイルが必要なコードのためにある。」シミュレータには何も要りません。「シミュレータSDKはarm64e.x1アーキテクチャを定義しないため、ビルドシステムはシミュレータビルドの実効アーキテクチャから、arm64eと同じようにこれを取り除く。」そしてAppleは実行時のオーバーヘッドを小さいと述べ、コストはサイズだとしています。「コストはバイナリサイズ、すなわち3つ目のスライスである。」³ ライブラリとフレームワークが必要とするのはビルド設定だけです。エンタイトルメントはメインの実行ファイルを起点に、システムがプロセス単位で付与します。そしてarm64eだけを同梱するライブラリでも、強制が有効なアプリが読み込めば恩恵を受けます。「ライブラリ内のload/store命令も引き続き検査される。」³

コードの変更については、「原則として不要。コンパイラがarm64e.x1スライスでチェック付き命令を生成し、『How to Enable』のエンタイトルメントが揃えばハードウェアがそれを強制する。」³ 例外は、演算が最上位バイトを乱すパターンで、文書はこう列挙しています。2つのアロケーションを指すポインタ同士の差、オブジェクト末尾を越えて持ち回されるオフセット、NULLをベースとする演算、そして整数型として扱われるポインタを含む演算です。安定性についての注記は一文だけ。「潜在的なポインタ演算のバグを抱えたコードはクラッシュする。」文書は、汚染を起こす命令とフォルトするデリファレンスが「別々の関数、別々のファイル、別々のライブラリにある可能性がある」と警告しています。³ 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はM6を8月25日、「Apple、まったく新しいM6とM5 Proを搭載したより高性能なMac miniを発表」と題したリリースでMac mini向けに発表しました。⁹ 発表済みと入手可能は別です。Appleの日程では、iPhone 18 Proと新しい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を採用しているアプリでは、表の最後の行を有効にし、強制用エンタイトルメントはまずブランチで追加しましょう。ハードウェアが手元に届いたら、EXC_ARM_CPA_FAILはすべてポインタ演算に関するバグ報告として扱い、クラッシュ地点ではなく汚染が起きた地点を探すことです。arm64eではフラグに手を出さないでください。ソフトウェアシーケンスはポインタ加算のたびに命令を消費しますし、賭けるならスライスのほうが得策です。Appleがリリースノートのリンク先の記事を公開するまでは、Xcode内部のリファレンス文書こそが、Appleが出荷した中で最も完全な説明です。

要点まとめ

iOSおよびmacOSのエンジニアへ: - arm64e.x1はMach-OのCPUサブタイプ12です。clangはこれに対して+cpa付きでapple-a20をターゲットし、ポインタ演算をaddptにコンパイルします。 - 強制には4つのスイッチが要ります。スライスのビルド設定、Enhanced Security、ハードウェアメモリタグ付け、そして桁あふれ用エンタイトルメントです。ビルドするのはarm64 arm64e arm64e.x1。

セキュリティおよびプラットフォーム責任者へ: - 強制下では、チェック付き演算命令が結果の最上位バイトをベースの最上位バイトと比較し、食い違えば汚染します。これによりメモリタグ付けに対する演算経由の迂回が塞がれます。ロードとストアのアドレス計算にも検査が及び、強制中のアプリが読み込んだ素の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スライスをビルドしたターゲットは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スライスはそれをターゲットする」と述べています。³

出典