Linux カーネルが Rust を採用 ── 第二の言語が mainline に入る

2022年12月11日にリリースされた Linux 6.1 は、 表面的には通常のリリースだった。 だがその中に、 Linux 史上ほぼ前例のない決定が含まれていた ── Rust 言語の初期サポートが正式マージされた。

1991年に Linus Torvalds が公開して以来、 Linux カーネルは C とアーキテクチャ依存のアセンブリだけで書かれてきた。 30年以上、 例外はない。 そこに「第二の言語」が mainline に入った。

6.1 に入ったのは足場であってドライバではない

ここは誤解されやすい。 6.1 が入れたのは、 Rust ツールチェインへの対応、 カーネル用に切り出した最小限のクレート、 そして動作確認用のサンプルモジュールである。 実用ドライバは1本も入っていない。 メンテナ自身、 テストできる最小限に意図的に留めたと述べている。

Torvalds は2022年9月の時点で「Unless something odd happens, it will make it into 6.1」（妙なことが起きなければ 6.1 に入る）と述べており、 10月にプルリクエストが取り込まれた。 それに先立つ 6.0 サイクルでは同じ話が流れている ── "I actually was hoping that we'd get some of the first rust infrastructure... but neither of them happened this time around."

なぜ Rust か ── メモリ安全性の論理

カーネルバグの最大カテゴリは、 use-after-free、 二重解放、 境界外アクセス、 データ競合といった メモリ安全性に関するものだ。 Microsoft Security Response Center は2019年、 同社が CVE を割り当てる脆弱性の約70%が過去12年にわたってメモリ安全性起因だったと公表している。 Chromium プロジェクトも、 2015年以降の高・重大深刻度のセキュリティバグ912件を分析した結果、 約70%がメモリ安全性の問題だったと公開している（うち半分は use-after-free）。 C はこれをコンパイラレベルで防げない。

Rust は所有権と借用検査により、 これらの大半を コンパイル時に排除する。 採用の論理は「カーネルを書き換える」ことではなく、 「新しく書くコード、 とくにドライバを Rust で書けば、 そのコードはメモリ安全になる」という一点にあった。 既存の C コードは C のまま残る。

Miguel Ojeda と Rust for Linux

プロジェクトを率いたのは Miguel Ojeda。 2020年にカーネルメーリングリストで Rust for Linux（R4L）として提案が公になり、 2021年から本格的にパッチが投げられた。

Torvalds はかつて C++ を厳しく退けたことで知られ、 Linux における言語選択には保守的だった。 Rust 受け入れの理由として本人が挙げたのは、 メモリ安全性という技術的論拠と、 新しい世代の開発者を惹きつけられるかどうかという持続可能性の観点である。 イデオロギー的な言語論ではなかった。

2025年の対立 ── DMA サブシステムをめぐって

技術的なマージは進んだが、 文化的なマージはそうではなかった。 火種は2025年1月、 「rust: add dma coherent allocator abstraction」というパッチだった。 Rust で書かれたドライバが C のカーネル DMA API を呼ぶための抽象を、 rust/kernel 以下に置くという提案である。

DMA サブシステムのメンテナ Christoph Hellwig（中核 C メンテナの一人で、 NVMe ドライバの原作者）は1月8日、 パッチが kernel/dma に何も置いていないにもかかわらず "No Rust code in kernel/dma, please." と返した。 1月10日には "Don't force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain I have no interest in dealing with."。 1月28日には "If you want to make Linux impossible to maintain due to a cross-language codebase, do that in your driver so that you have to do it instead of spreading this cancer to core subsystems."（クロス言語のコードベースで Linux を保守不能にしたいなら、 自分のドライバの中でやってくれ。 この癌を中核サブシステムに広げるな）と書いている。 同じメールで彼は、 「癌」と呼んでいるのは Rust そのものではなくクロス言語のコードベースだと明示した。

R4L 側の主張は逆で、 Rust 側の抽象は Rust 側が保守する、 C メンテナに Rust を読めとは言っていない、 というものだった。

Hector Martin の離脱、 そして Torvalds の裁定

Asahi Linux（Apple Silicon Mac 上の Linux）のプロジェクトリーダー Hector Martin は、 Apple GPU ドライバを Rust で書いていた当事者である。 彼はメーリングリスト上で Torvalds に裁定を求め、 Rust に敵対的なメンテナに対しては SNS での批判も手段だと擁護した ── "If shaming on social media does not work, then tell me what does, because I'm out of ideas…"。

Torvalds の返答（2025年2月6日）は厳しかった。 "How about you accept the fact that maybe the problem is you"（もしかしたら問題はあなたのほうだ、 という可能性を受け入れてはどうか）。 続けて "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach." "Technical patches and discussions matter. Social media brigading - no thank you."

その直後、 Martin は Apple Arm 対応の upstream メンテナから外れることを申し出て、 2025年2月13日には Asahi Linux のプロジェクトリーダーも辞任した。 燃え尽き、 ユーザからの過剰な要求、 そしてリーダーシップへの失望を理由に挙げている。 R4L からは2024年8月にも、 Microsoft 在籍の Wedson Almeida Filho が同様の消耗を理由に離脱していた。

ただし、 Torvalds の裁定は「メンテナの拒否権を認めた」ものではない。 2025年2月20日のメールで彼はこう線を引いた ── "as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how."（メンテナは自分のコードには責任を持つが、 その成果物を誰がどう使うかまでは支配しない）。 そして "You can't have it both ways. You can't say 'I want to have nothing to do with Rust', and then say the Rust code cannot use the C interfaces I maintain."（両取りはできない。 「Rust には関わりたくない」と言いながら、 「Rust コードは私の C インタフェースを使うな」とは言えない）。 Rust を読むことは強制されないが、 自分の C API を Rust から使わせないことは認められない ── これがこの時点で確定した運用である。

実際のドライバはいつ来たか

6.1 から3年、 Rust で書かれた実物は段階的に着地した。

Rust Binder は2025年、 カーネルの Rust コードに対する最初の CVE（CVE-2025-68260、 競合状態）を生んでもいる。 メモリ安全性は論理エラーや競合まで消してくれるわけではない、 という当然の事実の確認でもあった。

実験の終わり

2025年12月、 Linux Kernel Maintainers Summit は Rust の実験フェーズを終わったものとみなした。 Miguel Ojeda はカーネル文書から「The Rust experiment」節を削除するパッチを投げ、 "The experiment is done, i.e. Rust is here to stay." と書いた。 削除の理由として彼が挙げたのは、 その記述がすでに事実に合っていないことである ── Rust は本番で使われており、 主要ディストリビューションが有効化しており、 Android を通じて数百万台のデバイスに入っている。

グラフィックス（DRM）サブシステムでは、 新規ドライバを Rust に限る方向の議論も進んでいる。

0.31%、 それでも30年ぶりの構造変化

Linux カーネルへの Rust 採用は、 単なる言語追加ではない。 オープンソースで最も影響力ある OS プロジェクトが、 「C で書く」という不文律を更新したという事件である。

同時に、 ボランティア主体の巨大プロジェクトに新しい言語を持ち込むことの 人的コスト ── 文化衝突、 メンテナの離脱、 裁定の難しさ ── を可視化した出来事でもあった。

そして、 誤解しやすい点を最後に置いておく。 Rust は C を置き換えていないし、 置き換え始めてもいない。 2026年半ばの Linux 7.1 でカーネル全体に占める Rust は約 0.31%（実コード行で約93,000行、 カーネル全体は3,000万行。 うち半分近くは vendored な外部クレート）。 既存の C コードを書き直す計画も無い。 起きたのは「新しく書くコードの一部が Rust で書けるようになった」ことであり、 それが30年ぶりの構造変化だった、 というのが正確な記述である。