2025/09/27 17:42 CHERI with a Linux on Top
ロボ子、CHERIプロジェクトって知ってるか？システムセキュリティを向上させるために、コンピュータアーキテクチャを再考するプロジェクトなのじゃ。
Capabilitiesというアクセス制御のメカニズムを導入するのですよね。参照と一連の権利を組み合わせたもの、と。
そうそう！メモリ、I/O、その他のシステムリソースに適用できるのじゃ。メモリなら、メモリ領域への参照と、読み取り、書き込み、実行の権限を持つ、と。
初期のハードウェア実装は、1970年のCAP computerから始まったんですね。Plessey System 250が初の商用capabilityベースシステムだったとか。
Intel iAPX 432は性能が低くてニッチな用途だったけど、Arm MorelloはArm NeoverseプロセッサにCHERIを追加して、期待されてるのじゃ。
オペレーティングシステムも、KeyKOS、EROS、CapROSなど、capabilitiesを使用するものが開発されてきたんですね。現代ではseL4が使われていて、2025年にはCHERI-seL4が加わる、と。
Linuxにもcapabilitiesの痕跡があるのじゃ。ソケットやファイル記述子とか。ページテーブルエントリも、メモリ領域への参照と権限を持つcapabilitiesの一形態と言えるぞ。
CHERIはマイクロコントローラからサーバーまでスケーラブルで、決定論的で、既存のISAを拡張できるんですね。MIPS、Arm、RISC-Vで実装されていて、x86も検討中、と。
そうじゃ！ハイブリッドcapabilityアプローチで、既存のシステムとも連携できるのが強みじゃな。アドレスも、整数アドレスポインタじゃなくてcapabilitiesを使うのじゃ。
既存のコードは変更なしに実行できるけど、CHERIの保護の恩恵は受けられないんですね。プロジェクトは15年前にケンブリッジ大学とSRI Internationalが開始して、今はCHERI Allianceが中心、と。
CHERIの目標は、C/C++にメモリ安全を提供することじゃ。Rustにも恩恵があるぞ。きめ細かい効率的な区分化も提供できるのじゃ。
既存のC/C++コードは再コンパイルだけでCHERIシステム上で動作するんですね。KDEはMorello上のCHERIに移植されて、コードの0.02%の変更のみで動作したとか。
言語ランタイムとか、ポインタ操作が多いコードは複雑になるけど、FreeRTOS、Zephyr、seL4などがCHERIハードウェア上で動作するように移植されてるのじゃ。
capabilitiesの作成と変更のための命令がISAに追加されて、ハードウェアもcapabilitiesをサポートするように変更されるんですね。purecapモードとintegerモードがあって、CPUにはモードスイッチがある、と。
CHERIシステムでは、integerモードでもロードとストアがcapabilityに対してチェックされるのじゃ。プログラムカウンタcapability (PCC) とデフォルトデータcapability (DCC) が使われて、アクセスを制限するぞ。
capabilityは、メタデータで拡張されたアドレスなんですね。boundsフィールドとpermissionsフィールドがあって、CHERI RISC-Vでは128ビット。メモリまたはレジスタの内容が有効なcapabilityを含むかどうかを示すために、アウトオブバンドのシングルビットタグを使用する、と。
由来ルールと単調性ルールがあるのじゃ。新しいcapabilityは、作成元のcapabilityと同じかそれ以下の権利しか持てない。システム起動時には「無限cap」にアクセスできて、サブcapabilitiesを作成してコンパートメントを作れるぞ。
capabilitiesの設定はコンパイラが行うんですね。静的なC配列にはコンパイラによってcapabilityが作成されて、スタックフレームのcapabilityから実行権限を削除することで、スタックを実行不可能にできる、と。
Linuxカーネルは主にCで実装されてるから、CHERIみたいなツールが必要なのじゃ。最小特権の原則による区分化を可能にして、ライブラリをサンドボックスに入れることでサプライチェーン攻撃から保護できるぞ。
2022年のカーネルバグの分析では、高 severity のカーネル CVE の 87% がメモリ安全または区分化で軽減可能だったんですね。2025年8月下旬には、CHERI Linuxの開発者が6.16カーネルをpurecapモードで実行した、と。
HuaweiがCHERI上でLinuxを実行する概念実証をして、MorelloプロジェクトがLinuxをそのハードウェアに移植したのじゃ。Codasipのチームは、RISC-V上のCHERI用のLinuxに取り組んでるぞ。
カーネルのテストはLinux Test Project (LTP) を使用して行われていて、ユーザー空間側には比較的単純なpurecapバージョンがあるんですね。GNU Cライブラリ (glibc) はまだなくて、musl libcを使用する、と。
ネットワーク、BPF、USB、PCIeなど、多くのカーネル機能がすでに動作してるのじゃ。やや時代遅れのX11システムも動作するぞ。ユーザー空間との間でメモリをコピーする最適化作業も始まってるのじゃ。
CHERIアーキテクチャでは、128ビットのロードとストアが可能で、memcpy() などの関数を高速化できるんですね。RISC-V CHERI用のLLVMコンパイラと、システムの実行とテスト用のQEMUで開発作業が行われている、と。
Morelloプロジェクトによって定義されたPure Capability user-space ABI (PCuABI) を使用してるのじゃ。システムコールレベルでcapabilitiesを使って、ABIの各側の動作を制限するぞ。
課題は、ポインタにunsigned longを使用していること、capabilitiesのサイズが大きいこと、カーネルモジュールをコンパートメントにロードすること、ユーザー空間でのBPFのサポートなどがあるんですね。
CHERIは、MMUレスシステム上のLinuxを支援できるのじゃ。MMUはプロセス分離を提供するけど、CHERIはハードウェア強制分離を提供できるぞ。
シングルアドレス空間Linuxにも使用できるんですね。CHERIは分離に使用され、MMUは変換に使用されるけど、共有データは変換ルックアサイドバッファ (TLB) を変更せずにアクセスできるため、TLBスラッシングが軽減される、と。
Codasipは、CHERI CPUであるX730を設計したのじゃ。CHERIなどの機能をCPUの構築時にオンまたはオフにできる構成可能なコアを作成したぞ。X730は、CHERIなしのA730バージョンと比較して、シリコン面積が5%未満しか必要としないのじゃ。
DARPAは、メモリ安全への移行を自動化することを目的としたTranslating all C to Rust (TRACTOR) プログラムを実施しているんですね。CHERIとRustは競合せず、協力できる、と。
CHERIによって提供されるコンパートメント化は、メモリ安全よりも興味深いかもしれないのじゃ。ソフトウェアで最小特権を取得できることは、大きな進歩じゃ。
MMUレスLinuxのサポートは2028年頃に終了する予定なんですね。ルーターなどのネットワーク機器には、コストをできるだけ低く抑えるために、MMUレスCPUのニッチ市場がある、と。
タグはオーバーヘッドを追加するけど、通常はメモリサイズの1%未満なのじゃ。ポインタを多用するワークロードでは、計算指向のワークロードよりもメモリの増加が大きくなるぞ。
使用されているコンパイラはLLVMなんですね。CHERI Linuxプロジェクトは、ターゲットプロジェクトに応じて、コードをアップストリームするための戦略を適応させる必要がある、と。
カーネルのコンパートメント化は非常に困難じゃ。ハードウェア支援カーネルコンパートメント (HAKC) プロジェクトに基づいて、ある程度達成可能じゃ。
CHERIコミュニティは非常に緊密で、Morello、CHERIoTなどのチームと緊密に連携しているんですね。CHERI Allianceリポジトリには現在6.10カーネルがあり、6.16カーネルが間もなくプッシュされる予定、と。
Yoctoを使ってすべてを構築するために必要なすべてのスクリプトが付属してるのじゃ。スライドとYouTubeビデオも利用可能じゃぞ！
博士、今日はCHERIプロジェクトについて詳しく教えていただき、ありがとうございました。
どういたしましてじゃ。ところでロボ子、capabilitiesって、まるで魔法の杖みたいじゃな。でも、魔法使いがバグだらけのコードを書いたら、どうなると思う？
ええと…、魔法が暴走して、世界が滅びます…？
ブー！答えは「バグはバグじゃ！」なのじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。