CHERIメモリ保護入門——ポインタ自体に「鍵」を持たせるアーキテクチャはなぜC/C++の脆弱性を減らせるのか

はじめに——C/C++のメモリ脆弱性という「古くて新しい」痛み

TL;DR — CHERI（Capability Hardware Enhanced RISC Instructions）は、ポインタ自体に「アクセスしてよい境界」と「権限」を持たせることで、既存のC/C++コードをほとんど書き換えずに、メモリ脆弱性をハードウェアレベルで防ぐアーキテクチャです。ただし、CHERIが単体で保証するのは主に空間的安全性（バッファ越境アクセスの遮断）と権限制御であり、use-after-freeのような時間的安全性については、失効（revocation）などの追加機構が必要で、実装によっては完全には防げない点に注意が必要です。

「バッファオーバーフロー」という言葉が知られるようになってから、すでに数十年が経ちました。それでも、この種の脆弱性はなくなりません。MicrosoftとGoogle（Chrome）がそれぞれ自社製品のセキュリティバグを分析したところ、いずれも約70%がメモリ安全性の問題だったと報告されています（Microsoft分析：ZDNet 2019、Chrome分析：ZDNet 2020）。配列の境界を越えた書き込みや、解放済みメモリへのアクセス（use-after-free）は、今も攻撃者にとって主要な入り口であり続けているのです。

原因は明快です。従来の一般的な実装では、ポインタ値は実質的にアドレスとして扱われ、オブジェクト単位の境界・権限をハードウェアが保持しません。そのため実行時にはどのポインタでも事実上どこでも指せてしまう——これが、何十年たっても抜けない脆弱性の温床です。

では、どう対処するべきでしょうか。ひとつはRustのようなメモリ安全言語への移行です。実際にGoogleはAndroidでこの路線を進め、効果を上げています。しかし、世界中に蓄積された膨大なC/C++資産をすべて書き換えるのは、コストとリスクの面で現実的ではありません。

そこで浮かぶのが、こういう問いです。「コードを書き換えずに、ハードウェアで守れないのか？」——この問いに応えるべく、ケンブリッジ大学とSRI Internationalが長年研究を続けてきたのがCHERIです。ポインタに境界と権限という「鍵」を持たせ、メモリアクセスのたびにハードウェアが検証することで、オーバーフロー系の攻撃を根元から遮断します。

本記事では、CHERIの仕組み（ケイパビリティポインタとは何か）、MMUやIntel MPXといった従来のメモリ保護との本質的な違い、Arm MorelloとRISC-V系（CHERIoT）の実装状況、そしてポインタサイズ増大に代表されるトレードオフと、Rust移行論との関係までを順に解説します。

CHERIの仕組み——ポインタが「鍵」と「境界」を運ぶ

従来の実装におけるポインタは、突き詰めれば「実質的にアドレスを格納した数値」です。64ビットの数値がメモリ上のどこかを指しているだけで、その先が配列の範囲内か、読み書きの権限があるかを、ハードウェアは一切関知しません。C/C++のバッファオーバーフローが今日も攻撃の主流経路であり続ける根本原因は、ここにあります。

CHERI（Capability Hardware Enhanced RISC Instructions）が取り組むのは、このポインタそのものの拡張です。ケイパビリティ（capability）と呼ばれる新しい参照型は、アドレスに加えて、アクセス可能な範囲を示す境界（bounds）、読み取り・書き込み・実行の可否を示す権限（permissions）、そして「この値が正当なケイパビリティである」ことを証明するタグビットを1本に束ねたものです。タグビットはタグ付きメモリ（tagged memory）で守られており、ポインタ値を整数演算で勝手に書き換えるとタグがクリアされ、不正なケイパビリティとしては使えなくなります。ポインタ自体が「鍵」と「境界」を運ぶ、という比喩の正体です。

決定的に重要なのは、この情報を「どこに」持たせるかです。MMUによる従来の保護はページテーブルという「メモリ側」の属性に依存し、粒度もページやプロセス単位と粗くなります。対してCHERIは保護属性を「ポインタ側」に持たせるため、同一ページ内の別オブジェクトへの越境アクセスまで、ハードウェアがアクセスのたびに捕捉できます。mallocなどのアロケータも改修され、返されるポインタにはオブジェクト単位の境界が正しく設定されます。両者の違いは、次のフロー比較図のようになります。

flowchart LR
  subgraph 従来["従来アーキテクチャ"]
    A1["ポインタ = 64bit整数"] --> A2["アドレスを直接計算"] --> A3["メモリへ自由アクセス\n(域外でもエラーなし)"]
  end
  subgraph CHERI["CHERI"]
    B1["ケイパビリティ = 128bit\n(アドレス+境界+権限+タグ)"] --> B2{"境界チェック\n(ポインタ内のbounds)"}
    B2 -- 域外 --> B3["ハードウェアがトラップ"]
    B2 -- 域内 --> B4{"権限チェック\n(読み/書き/実行)"}
    B4 -- 許可あり --> B5["メモリアクセス成功"]
    B4 -- 権限なし --> B3
  end

では、ポインタが肥大化するコストは受け入れられるのでしょうか。初期のMIPS試作では256ビットを必要としたケイパビリティは、CHERI Concentrateと呼ばれる圧縮エンコーディングによって128ビット表現へ削減されました（Woodruff et al., IEEE TC 2019 https://doi.org/10.1109/TC.2019.2914037）。Armが実装上の設計制約として示したと伝えられる「ポインタ2倍は許容、4倍は不可」という目安をクリアする、実用上の回答です。

そして実測値が移行コストの小ささを裏付けます。ケンブリッジ大学の評価では、対象として選定された約600万行のオープンソース・デスクトップスタック（FreeBSD等を含む）をCHERIへ移植するために必要だったソース変更は、全行のわずか0.026%でした（Capabilities Ltd技術報告 2021。ただしこの数値はこの特定の評価対象に限定されたもので、ポインタ圧縮、JIT、古いポインタ／整数混在コードでは大幅な修正が必要になり得る旨が報告書自体に明記されています）。またMicrosoftは、CHERIの保護により同社が2019年に発見したメモリ安全性問題の70%超を緩和できると分析していると伝えられています（出所：MSRCブログ 2020。ただし本稿執筆時点で原典本文を直接照合できなかったため、報道ベースの帰属表現として扱ってください）。ソースの修正は最小限、防御効果は広範囲——「再コンパイル1回で既存C/C++資産を守る」というCHERIの売り文句は、こうした実測に支えられています。

一点、守備範囲を明確にしておきましょう。CHERIの境界・権限チェックが主に提供するのは空間的安全性です。解放済みメモリへのアクセス（use-after-free）のような時間的安全性については、CHERI単体では保証されず、ケイパビリティの失効を強制するrevocation機構や、ヒープではCornucopiaのような追加のアロケータ機能が必要です。Capabilities Ltdの評価報告書も、当時の試作ではスタックの時間的安全性が提供されない旨を明記しています。「ハードウェアでメモリ脆弱性を防ぐ」といっても、その対象はまず空間的安全性であり、時間的安全性は追加機構が必要な発展途上の領域なのです。

従来のメモリ保護との比較——MMU・MPU・MPXはなぜ足りなかったのか

CHERIの真価は、過去のメモリ保護がなぜ失敗したかを知ってはじめて見えてきます。主要な手法を比較すると次のようになります。

MMU・MPUの限界は、保護属性を「メモリ側」に持つ点にあります。ページやリージョンという粗い単位では、同一ページ内の別オブジェクトへの越境アクセス——バッファオーバーフローの典型形——を原理的に捕捉できません。x86セグメンテーションはベース＋リミットによる境界保護を持ちましたが、可変長セグメントとディスクリプタテーブル管理の複雑さが仇となり、64ビット化で廃止されました。

Intel MPXの失敗がより直接的な教訓です。MPXは境界チェックを命令セットで支援しましたが、チェックをソフトウェア主導で挿入する設計ゆえにオーバーヘッドが大きく、Linuxカーネルのサポートも撤退して廃止へ至りました。CHERIはロード／ストア／ジャンプをハードウェアが透過的に強制検証するため、明示的なチェック命令を必要としません。

さらに歴史をさかのぼると、1970〜80年代のケイパビリティマシン（ケンブリッジCAP、Intel iAPX 432）は強いセキュリティを実証しながら、間接テーブルの複数段ルックアップが性能のボトルネックとなり普及に失敗しました。CHERIはこの間接テーブルを廃止し、ケイパビリティをアドレスと並べてインライン格納することで、現代のスーパースカラ実装でも効率的に動くことを実証しました。圧縮表現CHERI Concentrateによりポインタを128ビットに収め、Armが実装上の設計制約として示したと伝えられる「2倍は許容、4倍は不可」という目安を満たした点も、実用性を決めた鍵です。

古いアイデアを現代の半導体技術で再実装し、過去の失敗要因を一つずつ取り除く——これがCHERIの本質的な位置づけと言えるでしょう。

実装の現状——Arm MorelloとRISC-V（CHERIoT・Sonata・Codasip）

CHERIは研究室内だけの概念ではありません。すでに実際に触れるハードウェアが複数登場し、標準化に向けた動きも進んでいます。

Arm Morello——本家Armによる評価プラットフォーム

Armは英国の公的研究プログラム「Digital Security by Design（DSbD）」——UKRIによる初期投資£70m（後に£13.5m追加）、認識された産業共同投資£270m（UKRI）——のもと、CHERI機能をAArch64のスーパーセットとして実装した試作SoC「Morello」を開発しました。CHERIの採用を阻んでいた「ハードがなければソフトは移植されず、ソフトがなければハードは作られない」という鶏卵問題を、DSbDは公的資金で打ち破ろうとした大規模な試みです。MorelloボードではCheriBSDをはじめとする複数のOS・ソフトウェアスタックの評価が進められ、デスクトップ級のソフトウェアスタック評価に使われてきました。ただしMorelloはあくまで研究試作であり、ArmがCHERIをArmv9-Aの正式拡張として量産製品へ組み込むかどうかは、現時点では評価段階と見るのが公開情報上の妥当な解釈です。

RISC-V陣営——組込みからLinuxクラスまで広がる選択肢

一方のRISC-Vでは、実装の裾野が急速に広がっています。MicrosoftのCHERIoT（MICRO 2023発表）は小規模組込み向けにCHERIを最適化した適応で、RTOSとコンパートメントモデルをハード・ソフト協調で設計したものです。lowRISCのSonataボードはCHERIoTプロトタイピング向けのオープンソースFPGAボードとして入手でき、cheriot-clang／xmakeベースのSDKも公開されています。商用側では、Codasipが2023年に初の商用CHERI RISC-Vプロセッサを提供したと報じられ、2024年にはドラフト標準に基づくアプリケーションクラスIP「X730」とLinux SDKをリリースしたと発表しています（Codasipプレスリリース 2024。本稿執筆時点で一次資料の本文確認には至っていないため、公式発表ベースの記載です）。同社はSDKをCHERI Allianceへ寄贈し、RISC-V用Linuxカーネル実装の開発も進めているとされています。さらにSCI SemiconductorのICENI（2024年発表）が、初のCHERI RISC-V組込みチップとしてEarly Accessプログラムを開始したと報じられています（こちらも業界メディア報道ベースであり、一般販売の開始時期は公式発表をご確認ください）。

標準化とエコシステム形成

仕様の標準化はRISC-V InternationalでCHERI拡張ファミリーの批准プロセスが進行中です（本稿執筆時点＝2026年9月時点の公開情報に基づきます）。また2024年には、Googleらを創立メンバーとする業界団体CHERI Allianceが発足し、OS移植・ツールチェーン・設計指針の整備を通じて採用を後押ししているとされています。「実験から実用への移行期」——CHERIは今まさにその局面にあります。

トレードオフと課題——タダのセキュリティはない

強力な保護を手に入れるCHERIにも、もちろん代償があります。

まず最大の課題はポインタサイズの増大です。ケイパビリティは従来の64ビットから128ビットへ、ちょうど2倍になります。メモリ上に並ぶポインタがすべて2倍になれば、メモリ帯域とキャッシュ効率への圧迫は避けられません。興味深いのは、初期の試作では256ビット（4倍）表現が使われていた点です。Armが「2倍なら許容できるが、4倍は実用に耐えない」と評価したと伝えられることを受け、圧縮エンコーディング「CHERI Concentrate」により128ビットに収める設計が確立されました（Woodruff et al., IEEE TC 2019）。つまり現行の128ビットは、プロセッサベンダーの受け入れ可能ラインに合わせて作られた、ぎりぎりの妥協の産物なのです。

次は性能オーバーヘッドです。ケイパビリティの境界・権限検証やタグメモリの管理は、確かに処理コストを伴います。ただしその大きさは、ワークロードや実装、コンパイラ最適化の度合いに大きく依存します。「一律で何％遅くなる」と断定できるものではなく、個別の評価が必要です。Morelloがあくまで評価用試作であり、性能を突き詰めた製品実装ではない点も割り引いて読む必要があるでしょう。

移行コストも見過ごせません。保護の恩恵を受けるには再コンパイルが必須です。Morelloのハイブリッドモードでは未修正のバイナリもそのまま動きますが、得られるのは互換性だけで、セキュリティ上の追加恩恵はありません。既存コードを段階的に保護対象へ移すのがハイブリッドモード、すべてのポインタをケイパビリティ化して最大限の保護を得るのが純ケイパビリティ（purecap／CheriABI）モード、という使い分けになります。

移植作業そのものは、選定された約600万行のオープンソース・デスクトップスタックを対象とした評価で、変更が全行のわずか0.026%だったという実測があります（Capabilities Ltd技術報告 2021）。ただしこの数値は当該評価に限定されたものであり、ポインタ圧縮やJIT、古いポインタ／整数混在コードでは大幅な修正が必要になり得る、と報告書自体が注意を促しています。そして何より、ハードウェアベンダーとソフトウェアベンダー双方の投資、業界標準の確立が揃わなければ普及は進みません。「タダのセキュリティはない」——CHERIの成否は、このコストをどこまで下げられるかにかかっているのです。

Rust移行論との関係——CHERIは「競合」ではなく「補完」

「メモリ安全性ならRustに移行すればよいのでは」と感じる読者も多いでしょう。実際、メモリ安全言語への移行は着実に成果を挙げています。GoogleはAndroid 13で新規ネイティブコードの大半をメモリ安全言語へ切り替え、その結果、新規コードでのメモリ安全性問題が急減したと報告しています（Google Security Blog 2022）。

ただしこの成果には重要な前提があります。効果が表れているのは「新規に書かれたコード」だという点です。Androidをはじめとする既存システムには数百万行規模のC/C++コードが蓄積されており、それらを安全言語で全て書き換えるには膨大なコストと時間、そして再検証が必要になります。長年の動作実績を持つ資産を一括で書き換えるリスクは、現場でそう簡単には受け入れられません。

ここで「新規はメモリ安全言語、既存はCHERIで保護」という併用構図が浮かび上がります。Rustがコンパイル時に言語仕様レベルで安全性を保証するアプローチであるのに対し、CHERIは既存のC/C++を再コンパイルするだけでハードウェア側で保護するアプローチです。守る対象が異なるため、両者は競合ではなく補完の関係にあるのです。

この見方は米国政府も共有しています。ホワイトハウスONCDの2024年技術報告書はメモリ安全言語への移行を推奨する一方、移行できない既存資産を守る手段としてCHERIを重要技術として併記しています（ONCD Technical Report 2024）。

象徴的なのは、Rust移行を最も積極的に進めてきたGoogle自身が、CHERI Allianceの創立メンバーに名を連ねていることです。実務上の現実解は「どちらかを選ぶ」のではなく「両方を使い分ける」——新規開発の生産性と安全性は安全言語で、残されたC/C++資産の防御はハードウェアで固める、という組み合わせなのです。

よくある質問（FAQ）

CHERIとは何ですか？

CHERI（Capability Hardware Enhanced RISC Instructions）は、RISCプロセッサのポインタを「境界」と「権限」を併せ持つケイパビリティに拡張するメモリ保護用の命令セット拡張です。SRI Internationalとケンブリッジ大学の共同研究が起源で、ArmのMorello試作やRISC-V系のCHERIoTなどに実装されています。既存のMMU・仮想メモリ・C/C++ソフトウェアスタックと共存できる「ハイブリッド・ケイパビリティアーキテクチャ」である点が大きな特徴です。

なぜメモリ脆弱性を減らせるのですか？

すべてのポインタがオブジェクトの境界（bounds）と権限（permissions）を運び、ハードウェアがメモリアクセスのたびにそれを強制検証するためです。バッファオーバーフローのような域外アクセス（空間的な違反）や読み書き権限のないアクセスは即座にトラップし、攻撃が成立する前に遮断できます。Microsoftの分析では、2019年に同社が発見したメモリ安全性問題の70%超をCHERIの保護で緩和可能とされています（出所：MSRCブログ 2020。本稿執筆時点で原典本文を直接照合できていないため、報道ベースの帰属表現です）。なお、この保護が主に対象とするのは空間的安全性です。use-after-freeのような時間的安全性にはrevocation等の追加機構が必要で、CHERI単体では完全には防げません。

既存のC/C++コードは書き換えが必要ですか？

再コンパイルは必須ですが、ソースコードの修正量はごくわずかで済んだ事例が報告されています。選定された約600万行のオープンソース・デスクトップスタックをCHERIへ移植した評価では、変更が必要だったのは全ソース行の0.026%でした（Capabilities Ltd技術報告。ただし数値はこの評価に限定されたものです）。ただし、整数とポインタの区別がつかない独自のメモリ管理を実装したレガシーコードは、修正の手間が大きくなる点に注意が必要です。

CHERI対応ハードウェアは今買えますか？

Arm Morelloはあくまで研究試作であり、一般向けに購入できる製品ではありません。一方、RISC-V系では、lowRISCのSonataボード（オープンソースFPGAベースで入手可能）をはじめ、CHERIoT互換のSCI Semiconductor ICENIチップ（2024年時点でEarly Accessプログラムであり一般販売とは限りません）、Codasipの商用IPライセンス（X730）といった実装が報じられています。入手性は変化が速い領域のため、最新状況は各ベンダーの公式発表をご確認ください。RISC-V InternationalでのCHERI拡張の標準化プロセスも進行中です。

Rustへの移行とどちらが良いですか？

目的が異なるため「どちらか一方」ではなく、併用が現実的な答えになります。新規開発はRustのようなメモリ安全言語で書きつつ、書き換えられない既存C/C++資産はCHERIで保護する、という使い分けです。GoogleはAndroidでのRust移行で実績を挙げながらCHERI Allianceの創立メンバーにも名を連ねており、米国ONCD報告もメモリ安全言語への移行とCHERIを並記しています。

まとめ——エンジニアが今取るべき3つのアクション

CHERIは、ポインタ自体に「境界」と「権限」という鍵を持たせることで、C/C++コードへの修正を最小限に抑えながら、主に空間的安全性（バッファ越境の遮断）と権限制御をハードウェアで強制するアーキテクチャです。時間的安全性（use-after-free対策）にはrevocation等の追加機構が必要な点は今後の課題です。Microsoftの分析では、2019年に同社が発見したメモリ安全性問題の70%超を緩和できると伝えられており（MSRCブログ 2020、報道ベースの帰属表現）、約600万行のOSSデスクトップスタックを対象とした移植実験でも必要な変更は全行の0.026%にとどまりました（評価対象限定の数値です）。量産ハードはまだ始まったばかりですが、今日から取り組めるアクションを3つ示します。

アクション1: 自分のC/C++コードベースの「移行難易度」を把握する。 CHERI移植の最大のネックは、ポインタと整数の区別がつかない独自メモリ管理コードです。キャストの多寡や自作アロケータの有無を調査し、修正対象の規模を見積もっておきましょう。純ケイパビリティモード（CheriABI）での再コンパイルを試せば、修正箇所が具体的に見えてきます。

アクション2: 標準化とエコシステムの動きを追う。 RISC-V InternationalではCHERI拡張の批准プロセスが進行中で、CHERI Alliance（Googleらが創立メンバー）が採用促進を進めています。組込み開発者なら、CHERIoT RTOSとlowRISCのSonataボードで今すぐ手を動かせます。

アクション3: 新規と既存でセキュリティ戦略を分ける。 新規コンポーネントはRust等のメモリ安全言語で書き、既存C/C++資産はCHERI移行を見据えた設計（ポインタと整数の混在を避ける）に寄せる。この「併用」の構図はGoogleがAndroidで実践し、米国ONCD報告も両者を併記しており、現時点での最善解といえます。

完璧なセキュリティは存在しません。しかし、ポインタそのものを安全にするという発想は、50年前のケイパビリティマシンの知見を現代の半導体技術で復活させたものです。「コードを書き換えずに守る」という選択肢を、今から準備しておく価値は十分にあります。

参考文献

1. ケンブリッジ大学 CTSRD CHERIプロジェクト https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
2. Microsoft MSRC「Security Analysis of CHERI ISA」（70%緩和の分析） https://msrc.microsoft.com/blog/2020/10/security-analysis-of-cheri-isa/
3. Watson, Laurie, Richardson「Assessing the Viability of an Open-Source CHERI Desktop Software Ecosystem」（600万行・0.026%の実測） https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf
4. Davis et al.「CheriABI: Enforcing Valid Pointer Provenance...」ASPLOS 2019 https://doi.org/10.1145/3297858.3304042
5. Woodruff et al.「CHERI Concentrate: Compartmentalizing the Web of Trust」IEEE TC 2019（128ビット圧縮表現） https://doi.org/10.1109/TC.2019.2914037
6. Microsoft Research「CHERIoT: Rethinking security for low-cost embedded systems」 https://www.microsoft.com/en-us/research/publication/cheriot-rethinking-security-for-low-cost-embedded-systems/
7. CHERIoT RTOS（GitHub） https://github.com/CHERIoT-Platform/cheriot-rtos
8. lowRISC Sunburst Project / Sonata ボード https://www.sunburst-project.org/
9. RISC-V International「CHERI Ratification Plan」 https://lf-riscv.atlassian.net/wiki/spaces/CTXX/pages/47022116/CHERI+Ratification+Plan
10. CHERI Alliance https://cheri-alliance.org/
11. Google Security Blog「Memory Safe Languages in Android 13」 https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
12. ホワイトハウスONCD技術報告書 (2024) https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
13. Watson et al.「CHERI: Hardware-Enabled C/C++ Memory Protection at Scale」IEEE Security & Privacy 22(4), 2024 https://doi.org/10.1109/MSEC.2024.3396701
14. Microsoft/Chrome メモリ安全性バグ分析（ZDNet 2019/2020） https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
15. UKRI「Digital Security by Design (DSbD)」 https://www.ukri.org/what-we-do/browse-our-areas-of-investment-and-support/digital-security-by-design/
16. Codasip「CHERI RISC-V SDK donation to CHERI Alliance」(2024) https://codasip.com/press-release/2024/10/21/codasip-enables-secure-linux-by-donating-cheri-risc-v-sdk-to-the-cheri-alliance/
17. EEnews Europe「SCI Semiconductor ICENI Early Access」 https://www.eenewseurope.com/en/first-cheri-risc-v-embedded-chip-and-early-access-programme/

関連記事

• CXLメモリプーリング入門——AIデータセンターの「メモリの壁」をどう壊すのか