Rust for Linux（カーネルモジュールのRust化）

なぜカーネルにRustが要るのか

Linuxカーネルの深刻な脆弱性の多くは、バッファオーバーフロー・use-after-free・二重解放といったメモリ安全性バグに起因します。カーネルモジュール は生ポインタを直接操作できる領域であり、1つのバグがシステム全体をクラッシュさせ、あるいは権限昇格の足がかりになります。Cはコンパイラがこれらを検査しないため、レビューとテストで防ぐしかありませんでした。

Rust for Linuxは、この構造的な弱点に言語仕様そのもので対抗する試みです。CやC++で書き直すのではなく、Rustコンパイラの所有権検査を通った新規ドライバ・モジュールを、既存のC実装と共存させる形でカーネルに組み込みます。全置換ではなく漸進的併存が現実的な戦略です。

所有権とライフタイムがバグをコンパイル時に消す

Rustのメモリ安全性の核心は、**所有権（ownership）とライフタイム（lifetime）**という2つの静的検査です。

• 各値には所有者が1つだけ存在し、所有者がスコープを抜けると値は自動的に解放される。
• 値の参照（借用）は、元の値が生きている間しか存在できない。コンパイラがこれを型として追跡する。
• 可変参照は同時に1つまでしか存在できず、不変参照と可変参照も同時併存できない。

この3規則により、use-after-free（解放済み領域への参照が型として作れない）、二重解放（所有者が1つしかないため解放は1回だけ起こる）、データ競合（可変参照の排他性がコンパイル時に強制される）が、実行前にコンパイルエラーとして検出されます。ガベージコレクタによる実行時オーバーヘッドは発生しません。検査はすべてコンパイル時に完結するため、カーネルが要求する予測可能なレイテンシとも両立します。

安全な抽象化層とunsafeの境界

カーネルは物理メモリの直接操作、割り込みハンドラの登録、DMAバッファの管理など、原理的にRustの安全性検査の枠外にある操作を必要とします。これらはunsafeキーワードで明示されたブロック内でのみ許可されます。

Rust for Linuxの設計方針は、unsafeを可能な限り薄く・少なく・低レイヤに閉じ込めることです。

[ドライバ実装層]  ← 安全なRust（unsafeなし）
       │  安全なAPI呼び出し
       ▼
[カーネル抽象化層] ← unsafeをラップし、不変条件を内部で保証
       │  FFI境界（extern "C"）
       ▼
[C実装のカーネル本体] ← struct file_operations等のCコード

抽象化層（kernelクレート）が、ロック・参照カウント付きオブジェクト・ファイル操作テーブルといったC由来の構造体を安全なRust型でラップします。たとえば「このポインタは呼び出し中ずっと有効」「この関数はロック保持中にしか呼ばれない」といったCコード側が暗黙に要求する不変条件を、抽象化層の実装者がunsafeブロック内で一度だけ検証し保証します。この保証さえ守られていれば、その上のドライバコードはunsafeを一切書かずに安全に組み立てられます。

C ABIとの相互運用

カーネル本体は膨大なCコードで構成されており、Rustモジュールはこれと直接やり取りする必要があります。この相互運用は2つの技術で支えられます。

bindgenは、カーネルのCヘッダを解析し、対応するRust側のFFI宣言（extern "C"関数宣言や構造体定義）を自動生成するツールです。手書きでは構造体レイアウトのズレやフィールド順の食い違いが起きやすいため、ビルド時に実際のヘッダから生成することで、CとRustの構造体表現を機械的に一致させます。

cバインディングのメモリレイアウト互換性は#[repr(C)]属性で明示します。Rustのデフォルトの構造体レイアウトはコンパイラが最適化のため自由に並べ替えてよいことになっていますが、#[repr(C)]を付けるとC言語と同じフィールド順・アラインメント規則でメモリに配置されることが保証されます。これがないと、Cコード側が期待するオフセットとRust側の実際のオフセットがずれ、未定義動作になります。

呼び出し規約の不一致やライフタイムの誤認識はbindgenやコンパイラでは検出できないため、FFI境界を跨ぐポインタの有効期間や所有権の受け渡しルールは、抽象化層の設計者が文書化されたC側の契約（例: このポインタは呼び出し先が解放するのか、呼び出し元が解放するのか）を読み取り、unsafeコードとして正しく実装する責任を負います。この契約はシステムコールのABI がユーザー空間とカーネルの間で守る規約と同じ性質のもので、境界を跨ぐ規約はツールが自動保証できず、人間の理解に依存する領域です。

既存Cコードベースとの共存

Rust for Linuxは、既存のCサブシステムを置き換えるのではなく、新規ドライバやモジュールをRustで書けるようにする追加の選択肢として統合されています。ビルドシステムはCとRustのオブジェクトファイルを両方生成し、最終的に単一のカーネルイメージへリンクします。

この共存戦略には明確な利点があります。数千万行に及ぶ既存のC資産を一度に書き直すコストとリスクを避けつつ、新規に書かれる部分からメモリ安全性の恩恵を受けられます。実際に採用が進んでいるのは、Androidのバインダドライバや一部のGPU・ネットワークドライバなど、比較的独立性が高く新規実装しやすい領域です。既存のCコードの安全性は変わりませんが、新規コードのバグ密度を下げることで、カーネル全体のバグ発生率を漸進的に下げる狙いです。

まとめ