10月24日、Phoronixが「systemd Merges Support For Rust Programs」と題した記事を公開した。Linuxシステムの根幹を担うsystemdのGitリポジトリに、Rustプログラムのサポートがマージされたことを伝えている。

Linuxカーネル本体へのRust導入が進む中、systemdという「もう一つの心臓部」にもRustが入り込んだ。ただし、その方針はRustコミュニティの慣習とは大きく異なる。パッケージマネージャーのCargoを使わず、既存CコードのRust移植も行わない——低レイヤーインフラならではの慎重な判断が随所に見られる独自路線だ。

今回マージされた変更（PR #44324）により、systemdの各種プログラム（リーフコンポーネント：他のコンポーネントに依存されない末端の独立したプログラム）をC言語の代替としてRustで記述できるようになった。将来リリースされるsystemd 263に含まれる予定だ。ただし、重要な留保がある。systemdライブラリなどのコアコードはまだRustに対応していない。コア部分への導入を阻む技術的障壁が残っており、現時点では周辺の独立したコンポーネントのみが対象となる。

今回のRustサポートのきっかけとなったのは、**systemd-keyring-setup** という新コンポーネントだ。ブートプロセス中にキーリングのプロビジョニングを行い、X.509証明書をカーネルのdm-verity（ブロックデバイス整合性検証）・fs-verity（ファイルシステム整合性検証）・BPFキーリングへエンロールする役割を担う。セキュリティ上の誤りが許されないブートタイム処理をRustで実装する選択は、Rustのメモリ安全性への期待を端的に示している。systemd-keyring-setupのコード自体は現時点でまだマージされていないが、インフラの着地を受けて近日中にマージされる見込みだ。

systemd開発チームが採った設計方針は三点にまとめられる。第一に、Cargoを使用せず、ビルドシステムは既存のMesonに統一する。第二に、CリンケージのみをRust-C境界に許可し、呼び出し規約をCに限定する。第三に、既存CコードのRust移植は行わない——新規コンポーネントのみRustで書くという方針だ。

Cargoを排除する理由は明快だ。外部クレート（Rustのライブラリ単位）への依存はサプライチェーンリスクを生む。systemdのような低レイヤーインフラが多数の外部依存を抱えることは、セキュリティ面でも保守面でも大きなリスクになりうる。他のLinuxシステムコンポーネントが慣習的なRustエコシステムと距離を置く傾向とも一致した判断だ。

バイナリサイズについても実測値が公開されている。テストプログラムでの比較では、RustビルドはCビルドより約60%大きい（32KB対20KB）。現時点の数字であり最適化の余地はあるが、組み込み環境やリソース制約の強い環境では考慮が必要な点だ。現在のRustサポートはオプション扱いで、Mesonの -Drust= オプション（enabled / disabled / auto を指定可、デフォルトは auto）で制御できる。

Linuxカーネルに続き、systemdほど広く普及したシステムソフトウェアがRustを正式に取り込んだことで、低レイヤー領域におけるRustの存在感はいっそう増した。Cargo排除・移植禁止という制約がどこまで維持されるか、そして今後どのコンポーネントがRustで実装されていくかが次の注目点となる。

詳細はsystemd Merges Support For Rust Programsを参照していただきたい。