パフォーマンス、安全性、並行性を重視した最新のシステムプログラミング言語であるRustは、新しいオペレーティングシステムの開発に最適な選択肢のように思えます。そして、既にいくつかの同様のプロジェクトが存在します。そして今、新たなプロジェクトであるTheseusが登場しました。これは、開発者のKevin Boos氏が「オペレーティングシステムの構造と状態管理の実験」と表現しています。
Theseus の背後にある主要な考え方は、Boos 氏とライス大学およびイェール大学の他の 3 人の寄稿者が「州の流出」と呼ぶものを避けることです。
昨年 11 月に開催されたオペレーティング システムの設計と実装に関する USENIX シンポジウムで発表された論文で、研究者らはこれを「あるソフトウェア コンポーネントが別のコンポーネントからのやり取りを処理した結果、状態が変化し、その将来の正確さがその状態に依存する状態」と定義しました。
Theseusのコード編集：開発者はVisual Studio Codeを推奨
これは現代のシステムでは当たり前のことだと彼らは述べ、Androidのシステムサービスに障害が発生すると「ユーザー空間フレームワーク全体」がクラッシュし、障害の発生したサービスを使用していないアプリケーションも含めたすべてのアプリケーションに影響を及ぼすことを例に挙げた。
状態の漏洩は信頼性の障壁であり、小型ペースメーカーのファームウェアからデータセンターのネットワークに至るまで、あらゆるものに影響を与えると研究者らは主張した。「OSコードにおいて状態の漏洩をどの程度回避できるか」を探るため、研究者らは所有権モデルを持つRustを選択し、ゼロから新しいOSを作成することを決定した。
Rust のドキュメントで「Rust の中心的な機能」と説明されている所有権は、言語がメモリの安全性を実現する鍵であり、次の 3 つのルールを強制します。
- Rustの各値には、その所有者と呼ばれる変数があります。
- 一度に所有者になれるのは1人だけです
- 所有者がスコープ外になると、値は削除されます
研究者らは、状態の漏洩を回避するにはOSの構造、特にOSのモジュール化方法を再考する必要があると述べた。Theseus OSは、明確な境界を持つセルと呼ばれる多数の小さなコンポーネントで構成されており、セルはRustのクレート（プロジェクトコンテナ）をベースにしている。
しかし、より大きな革新は、彼らが「イントラリンガルOS設計」と呼ぶもので、これはプログラミング言語のメカニズムを用いてOSを実装することを意味します。その考え方は、「セマンティックエラーを実行時エラーからコンパイル時エラーへと移行する」というものです。
つまり、Theseus は他の Rust ベースのオペレーティング システムよりも Rust と深く結びついています。
TheseusのセルはRustのクレートであり、問題の修正やOSのアップデートのために交換することができます。
状態管理は、クライアントサーバーモデルに基づく原則に基づいて処理されます。クライアントは自身の状態を所有し、サーバーはステートレス通信を使用します。これは、「特定のリクエストを処理するために必要なすべてのものが、そのリクエストに含まれている必要がある」というものです。
これはREST Webモデルではお馴染みのものです。そのため、Theseusはハンドルやオペレーティングシステムが所有するリソースへのポインタといったものを避け、リソースを直接所有することを優先しています。
Theseusのレジリエンスは、セルスワッピングと呼ばれる手法を用いています。この手法では、新しいセルが既存のセルを置き換え、それらの依存関係を引き継ぎます。古いセルは、他のセルから参照されなくなるまで、実際には削除されません。
障害回復には、破損したセルを新しいセルに置き換えることが含まれる。研究者らは、これにより「複数のサブシステムに障害が発生した場合でも、Theseusは最下層のシステムにおける障害を許容できる」と主張している。
同様のメカニズムにより、ライブアップデートも可能になります。研究者らは障害回復のテストにおいて、80万個の障害を注入し、69%の回復成功率を達成しました。
パフォーマンスはどうですか?
「Theseus が Linux のような既存の OS より全般的に優れているとは主張しませんが、結果はパフォーマンスの重大な欠点を示していません」と研究者らは LMBench などのテストに基づいて述べた。
実験的なアーキテクチャにもかかわらず、限界は存在します。研究者らは、ハードウェアとのやり取りが必要となるため、アンセーフコードは「低レベルのカーネル環境では残念ながら避けられないもの」だと述べています。また、コンポーネントは安全なRustで実装する必要があるという制約もあります。
他の「安全または管理された」言語はサポートできますが、安全でない言語はハードウェアまたはソフトウェアによる分離が必要になります。また、設計者はファイルシステムなど、一部の領域で原則を妥協しています。
「完全にスピルフリーな FS は、現在ファイルにアクセスしているクライアントにファイルの唯一の所有権を与えることで既存の POSIX インターフェースを破壊します。つまり、クライアントがファイルを解放するまで、ファイルは存在しないように見えます。」
それは不便ですね。現状では、従来のファイルシステム標準をサポートしつつ、このケースでは状態漏洩を受け入れるという「トレードオフ」があります。
Theseusは現在GitHub上に公開されており、38,000行のRustコードと900行のアセンブリコードで構成されています。このオペレーティングシステムは、Linux、WSL（Windows Subsystem for Linux）を使用したWindows、macOS、またはDockerコンテナ上で構築できます。QEMUエミュレータで実行できます。
チームは開発に Visual Studio Code を愛用しており、「Rust のクロスプラットフォーム サポートが優れている」と述べています。「他の選択肢もありますが、お勧めしません。」
もう一つの著名なRustベースのOSはRedox OSで、現在バージョン0.6です。前回のメジャーアップデートは12月に行われ、カーネルメモリマネージャの完全な書き換え、多くのコンポーネントの更新と新規追加（多くのユーザーアプリケーションで使用されるrelibcライブラリの大幅な改良を含む）、そしてpkgarと呼ばれる新しいパッケージフォーマットが含まれています。
Redox OSは、もう一つの有名なRustベースのOSですが、より馴染みのあるUnix風のデザインになっています。
Redox があるのに、なぜ Theseus を気にする必要があるのでしょうか?
答えは、Rustの使用と新しいオペレーティングシステムであること以外に、両プロジェクトに共通点はほとんどないということです。RedoxはUnixライクなシステムコールをサポートし、ドキュメントによると「MINIXに大きく影響を受けた」アーキテクチャを備えています。
Redoxは開発者にとって馴染み深いものとなるでしょう。ただし、Redoxはコンポーネントの分離、1つのコンポーネントの障害による他のコンポーネントのクラッシュへの耐性、そしてコンポーネント間の通信制限など、高い耐障害性を目指しています。Redoxの設計者によると、Redoxは「コンピュータシステムの問題を最小限に抑えたいユーザー向け」とのことです。まさに私たちのほとんどがそうでしょう。
Rustベースのオペレーティングシステムとしては、組み込みシステム向けに設計されたTockがあります。他にもいくつかありますが、ほとんどはあまり活発ではありません。
Theseus が提起する疑問は、Linux (および Linux ベースの Android)、macOS、Windows などの既存のオペレーティング システムに多大な投資がなされている世界で、根本的に異なる新しいオペレーティング システムが、それを確立する際の大きな困難を克服するのに十分な利点を持つことができるかどうか、ということです。
GoogleはFuchsiaで良いチャンスを掴んでいるかもしれない。しかし、Rustベースの選択肢も魅力的で、このプロジェクトやRedox OSのようなプロジェクトは注目に値する。®
