Maestro: Linux互換を目指すRust製カーネル
(blog.lenot.re)- Maestro は、日常利用が可能な程度に Linux と互換性を持ちながら、軽量な Unix 系オペレーティングシステムを Rust で新たに作ろうとするプロジェクト
- 2018年に学校のプロジェクトとして始まり、当初は C言語 で実装されていたが、コードベース管理の問題とカーネル開発における安全性の必要性から Rust に移行
- 現在は x86 32ビット向けの モノリシックカーネル で、Linux システムコール 437個のうち 135個がある程度実装されており、約31%の水準
- ブートシステム・デーモン管理ツール Solfège、システムユーティリティ、パッケージマネージャー blimp も併せて開発しており、musl、bash、一部の GNU coreutils も動作
- まだ非常に初期段階で不安定であり、QEMU・VMWare・VirtualBox でのテストが中心のため、重要なデータがあるマシンにはインストールしないほうが安全
Maestroの目標と出発点
- Maestro は、Rust でゼロから書かれた Unix 系オペレーティングシステム
- 目標は、軽量で、日常利用が可能な程度に Linux と十分な互換性を持つシステムを作ること
- システムを A から Z まで自分で理解し、望む形にカスタマイズできる環境を作るために始まった
CからRustへ移行した理由
- 最初のコミットは 2018年12月22日 03:18 に作成され、プロジェクトは学校課題としてスタート
- 初期実装は約1年半にわたって C言語 で進められたが、コードベースをきれいに保つのが難しくなった
- Rust で再スタートして得られた利点
- 以前の失敗から学んだことをもとに、プロジェクトを最初から再設計できる
- 単に C で Linux に似たカーネルを書き直すよりも、新しい試みができる
- Rust の型システムにより、メモリ安全性の責任の一部をプログラマーではなくコンパイラに任せられる
カーネル開発でRustが有利だった点
- カーネル開発のデバッグは一般的なアプリケーションよりはるかに難しい
- 文書を見つけにくく、BIOS 実装自体に欠陥があることもある
- 起動時、カーネルはメモリ全体にアクセスできるため、自分のコードのような誤った場所にも書き込めてしまう
- メモリリーク追跡に valgrind のようなツールを使えない
- gdb は QEMU・VMWare と一緒に使えるが、エミュレーターや仮想マシンによってカーネルの動作が異なることがある
- VirtualBox のように gdb をサポートしない環境もあり、QEMU・VMWare の gdb サポート機能にも一部不足があり、gdb がクラッシュすることもある
- こうした問題を減らすには、メモリ安全な言語 がカーネル開発でも有利
- Rust はカーネルにさまざまな安全機構を入れる助けとなり、プロジェクトで最良の判断だったと評価されている
現在の実装状況
- Maestro は現在 モノリシックカーネル で、x86 32ビットアーキテクチャのみをサポート
- 執筆時点での実装状況
- Linux システムコール 437個中135個 がある程度実装されている
- システムコール実装率: {p:31}
- 全リポジトリ合算で 615ファイル、48,800行 のコードがある
- 行数は
clocコマンドで計算
- カーネル以外の OS 構成要素
- Solfège: systemd にある程度似ているが、より軽量なブートシステム・デーモン管理ツール
- maestro-utils: システムユーティリティコマンド集
- blimp: パッケージマネージャー
- そのほかの構成要素も GitHub で公開されている
- 動作が確認されたサードパーティソフトウェア
- musl C標準ライブラリ
-
bash
ls,cat,mkdir,rm,rmdir,uname,whoamiなど一部の GNU coreutils コマンド- オリジナルの neofetch は Maestro を認識しないため、パッチを当てた neofetch バージョンが必要
自分で試す方法と制約
- OS はまだ非常に初期段階で、非常に不安定
- 重要なデータがあるマシンへのインストールは推奨されない
- これまで主に QEMU、VMWare、VirtualBox でテストされている
- インストール方法は2つ
- 事前ビルド済みの圧縮
.isoファイルをダウンロード - ISOを自分でビルド
- 事前ビルド済みの圧縮
- ISO には OS インストーラーが含まれており、QEMU、VMWare、VirtualBox などで実行できる
- ISO の実行には十分な RAM が必要で、1GB あれば足りる
- インストールするパッケージがディスクではなく initramfs の RAM に保存されるため
- 現在の OS は USB メモリや CD-ROM を直接読み取れず、ブートローダーに依存しているため
記事で扱うテーマ
- 目的は OS 制作チュートリアルを書くことではない
- OS 制作の基礎資料としては osdev.org と Philipp Oppermann’s blog が推奨されている
- 今後は、より高度なテーマ、問題解決の過程、コンピューター・オペレーティングシステム・インターネットが内部でどう動くかを扱う予定
今後の開発方針
- 優先順位は コードベースの整理 と性能最適化
- 学校プロジェクトとして始まったため、スケジュールに合わせるための近道を選んだ部分があり、蓄積した技術的負債を返済する必要がある
- 一部のメモリリークも修正する必要があり、性能最適化は記事のテーマにもなりうる
- 次の大きな目標は、パッケージマネージャーを OS 上で完全に動作させること
- ネットワークサポート が必要で、現在開発中
- 共有ライブラリ対応 が必要
- 共有ライブラリはファイルをメモリに直接マッピングする必要があるが、現在のカーネルの
mmapシステムコール実装はこれをサポートしていない
- その後は gcc/g++, clang, rustc, make, Git, Vim のようなプログラムをより簡単にインストールしてテストできるようになる
- 最終的には、Maestro 上でカーネルを開発する流れを目指す
カーネル完成度を高める開発手順
- 開発は、プログラムをカーネル上で実行してみて、動かなければ原因となるシステムコールを見つけて実装または修正する方式で進められる
- プログラムをカーネル上で実行する
- 動作しなければシステムコール出力を見て、最初に問題を起こすシステムコールを探す
- そのシステムコールが未実装またはバグがあれば、実装または修正する
- 再びプログラムを実行する
- より多くのプログラムがカーネル上で正しく動作するほど、カーネルはより 安定 し、完成度が高まる
1件のコメント
Hacker News のコメント
応援してくれて本当にありがとう。このプロジェクトに多くの努力を注いできたので、とても大きな意味がある
今ウェブサイトがかなり遅いか落ちているようだけど、予想以上にトラフィックが多く、DoS 攻撃も疑われる
今は仕事中ですぐに集中するのは難しいけれど、家に帰ったらもっとうまく動くように直してみる
2010年に Rust がなかった頃、大学を出た直後に C で Unix 系の趣味 OS を少しいじっていたことがあって、本当に楽しかった
ここまで進める時間を取れたのがうらやましい
ナビゲーションバーが画面の 33% くらいを占めていて、消すこともできない
なぜ人はこういうものを固定して、貴重な読書スペースを奪うのか分からない。必要なら 300ms くらいで一番上までスクロールできるのに
小さくて素敵なプロジェクトだ。Linux のシステムコールの 3 分の 1 も実装していないのに、ここまで起動しているのは驚きだ
ただし、欠けているものほど複雑である可能性が高い。たとえばTTY レイヤーは今かなり基本的な水準に見えるし、ちゃんと作るにはまだ多くの作業が必要そうだ
だから今後 3 年以内に Maestro が Linux アプリケーションを動かすようになるとは期待しにくい。Linux にある何千ものドライバを考慮しなくてもそう思う
成熟したプラットフォームは多くのシナリオを支えるためにロジックが積み重なっていき、その結果、ほとんどのケースではシステム全体の大半を必要としなくなる
「誰も Excel の 10% 以上は使わないが、それぞれが使う 10% は違う」という話に近い
Excel 関数の 30% だけ実装しても、世の中のスプレッドシートの 99% を開けるエンジンは作れるだろう。ただし完全なドキュメント互換性が欲しいなら、まだ道のりは長い
あるシステムコールは特定のコードパスでしか呼ばれなかったり、新しいカーネルを対象にしたときだけ必要になる新しい呼び出しだったりする
システムコールは数が多く、その中にはかなり厄介なものもある。完全にオープンな代替実装なら最終的にその大半をサポートする必要があるだろうが、3 分の 1 なら良い出発点だ
[1] VM をベアメタルで動かすか、VM として起動したくて、
init=/path/to/the/vmのようなものを除けば、これが最小の労力でそこに到達する方法に見えた。ただ、その方法では自分が本当に欲しかったもの、つまりハードウェアドライバと TCP スタックを VM 言語の中に置くことはできない実用的になるために Steam、LibreOffice、Firefox まで動かす必要はないと思う。一般的なサーバやマイクロサービスアーキテクチャの多くの構成要素は、やっていることが比較的単純で、安全で単純なカーネルからかなり大きな恩恵を受けられそうだ
Rust 製のモノリシックカーネルで、Linux ABI 互換性を目標にしていた Kerla もある。ただ、数年来休眠状態のようだ
[1] https://news.ycombinator.com/item?id=28986229
マイクロカーネル設計で、おそらくもう少し成熟している。MIT ライセンスなのでコード共有の余地もありそうだ
「Rust で書かれているというだけで、有能なハッカーが何か見つけられるのか」を見るために、セキュリティ/侵入テスト/ファジングをしてみると面白そうだ
ファジングテストや侵入テストをすれば、問題がたくさん出てくると 100% 確信している。まだそこに時間を使う余裕がなかった
今は中断している Kerla プロジェクトで、すでに試みられていたことのようだ
面白いプロジェクトに聞こえる。ただ、C を使う欠点や OS 開発の難しさの大半はデバッグにあると思う
Rust に移ることで特定種類のメモリエラーはなくなっただろうけど、デバッグは今もなおつらいのか？ それとも以前より減って耐えられるようになったのか気になる
デバッグは今でもつらいが、以前よりはずっとましだ
たとえばミューテックスを使うのを忘れる可能性は高くない。コンパイラがエラーとして教えてくれるからだ
とはいえ万能ではなく、デッドロックのような問題は依然としてある。特に割り込みが絡むとそうだ
たとえばミューテックスをロックした状態で割り込みが発生すると、そのミューテックスをロックしていたコードは割り込みが終わるまで停止する。ところが割り込み処理のコードが同じミューテックスをロックしようとするとデッドロックが起き、型システムではこうした問題を助けられない
解決策はミューテックスがロックされている間、割り込み処理を無効化することだが、コンパイラがそれを強制することはできない
少し脱線するが、作者がコントリビューション動画で使っていた Gource が気に入った
以前は見たことがなかったが、数年前に似たようなものを作ってみようというアイデアはあった。やはり完全に新しいアイデアというのはないようだ
特に学習目的なら、カーネルを自作することは本当に素晴らしいと思う。カーネルや OS 全般を理解するのにどんな資料を使ったのか気になる
Theseus OS が出てこないのは意外だ。Rust でゼロから作られている開発中の OS で、Rust コンパイラのメモリ安全性保証を利用して、従来の OS なら慎重に配線しなければならない多くのことを自動的に提供する
たとえば単一特権レベル、単一アドレス空間の構造でも安全だ。OS のすべての部分がホットプラグ可能だ
欠点はネイティブコードがすべて Rust でなければならない点だが、昨年WASM ランタイムが実装された。3 年前の関連スレッド:
https://news.ycombinator.com/item?id=25741729
ft_penguin プロジェクトをやり切るほど狂った人がいるとは思わなかった。まだその名前で合っているか分からないけれど、正直本当にすごい
7 年前に学校にいた頃は、必要な時間に対して見返りが最も悪いプロジェクトのひとつだと思っていた
最初は友人と一緒に始めたのか、Rust で書き直す前はどうだったのか気になる。同時に他のプロジェクトもやっていたのかも気になる
コードを見て楽しかった記憶がよみがえって、今では DevOps の仕事をやめて、もともとやりたかった組み込みや別の低レベル作業をしたくなってきた