Rustは銀の弾丸となり得るか　新しいOS開発を実現する可能性

EVENT

Kernel/VM探検隊online part2

2021年03月20日に開催

Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。garasubo氏からは、「Rust」で新しいOSの設計を試みる3つのOSについて発表がありました。

スピーカー

garasubo

「Rust」で新しいOSの設計を試みる論文を紹介

garasubo氏：よろしくお願いします。「RustはOS界の銀の弾丸になりうるか　論文で見るRustで変わるOS設計」というタイトルでgarasuboが発表します。内容を詰め込みすぎちゃったので、けっこう駆け足の発表になると思いますが、ご了承ください。

Rustは、OSを書くにあたってC言語の代わりになるんじゃないかといろいろと注目されてきていて、今回は3つの論文を紹介します。論文はRustを使って新しいOSの設計を模索するというものです。

1つ目がSOSP2017（Symposium on Operating Systems Principles　2017）で発表された「Tock」というOSで、残り2つは2020年のOSDI（Operating Systems Design and Implementation）で発表された「ReadLeaf」と「Theseus」というOSを作った論文です。これらの内容を全部紹介するのは無理なので、Rustの性質をうまく活かせているところをピックアップして紹介していきたいと思います。

アプリケーション間の独立性を保ちながら柔軟性も提供する「Tock」

最初がTockというOSです。何度か私もブログで紹介しているんですが、これは省メモリなマイクロコントローラ用のとして設計されたもので、ArmのCortex-Mみたいな、すごくメモリ領域が限られたものを想定したOSです。

Tockの目的の1つがアプリケーション間の独立性を保ちつつ、アプリケーション内の柔軟性がほしいというもので、具体的には例えば1つのプロセスがたくさんメモリを使っても他のプロセスは無事にさせたいということです。従来だとメモリを確保するときは静的に何個か配列を作っておいて、各プロセスに割り当ててしまうことがけっこうあります。

そうすると定数で確保しちゃうので、最大値の制約の付け方が難しくなります。そこでmallocみたいに動的に確保しようとすると、あるプロセスがたくさんメモリを使ってしまって他のプロセスが足りなくなって、プロセス間の独立性が損なわれてしまう危険性がありました。

それを解決するためにTockにはGrantsという仕組みがあります。プロセスがシステムコールを呼び出すときに、動的にメモリを確保する必要があるケースで使うものです。例えばタイマードライバがあって、新しいイベントを登録したい。そのイベントのメタデータをメモリ上に置いておきたいというときにメモリを確保する必要があります。

Grantsには、プロセスごとにメモリ領域があって、そのメモリ領域の一部をOS側に貸し出します。その貸し出した仕組みをGrant型としてRustで実装して、カーネルはGrant型を利用してそのメモリ領域を触ります。

メモリ領域を自分から貸し出すので、メモリをたくさん使って困るのはプロセスだけになります。Grantのインターフェイスによってコンパイラがこの領域の安全性を保証するという仕組みです。

これが実際の実装で、ライフタイム制約によってOwned型なので、カーネル側はメモリ内部を触るんですが、ライフタイム制約が付いているので他のプロセスには渡せません。Result型でCopy型のRなので、エラーコードなどは返せるようになっています。

「Rust」を使って障害を切り分ける「ReadLeaf」

次のReadLeafですが、これはx86ベースのアーキテクチャ用で、Rustを使って実装されたマイクロカーネルベースのOSです。基本的なコンセプトはハードウェアのアドレススペースではなくて、Rustの言語機能を使ってfault isolationを実現しようというものです。

最終的にはPOSIXのサブセットまで実装して、ネットワークドライバで実際に実装して比較実験をしています。今回見るのはドメイン間通信のところです。ドメインごとの独立性を担保しつつ、ドメイン間通信を実現するためにRustの言語機能を使っているのを見ていきます。

ドメイン間通信は効率良くやりたいので、共有のヒープ領域を利用するんですが、例えばあるドメインが共有のヒープ領域から確保されたオブジェクトを抱えたままクラッシュすると、抱え落ち状態になって困るという問題があります。これをどうしたかというと、共有ヒープの領域をRRef型でラップして、この型を介してアクセスしています。

この型は、「どのドメインがこのオブジェクトを持っている」という情報をきちんともっているので、クラッシュしたときはそのRRef型に入っている情報を利用して、よしなに対処してくれます。ドメイン間のインターフェイスはIDL（ Interface Definition Language）で自動生成されるんですが、そのときにRRef型などCopyを実装したものでないと引数にできません。

抱え落ちするオブジェクトが生まれるインターフェイスが作れないように各ドメインを設定しています。

OSコンポーネント間でのステートスピル削減に焦点を当てた「Theseus」

最後にTheseusというOSです。これが一番アーキテクチャとして尖っているなと個人的に思っています。これもx86を対象にして作られていて、OSのコンポーネント間でのステートスピル、状態が他のコンポーネントに漏れ出すというのがOSのバグの原因としてよくあるらしくて、それをいかに少なくするかということに焦点を当てて設計したRust製のOSです。

どうやって実現したかというと、OSの実行モデルと言語の実行モデルをできるだけ近づけてコンパイル時の静的チェックを最大限利用しています。

言語を実行モデルと一致させるのは、すべてのコンポーネントをシングルアドレススペースで、同じ権限上で動かしています。

タスク管理を見てみます。Theseusでは標準ライブラリのスレッドではなくて、独自のタスク抽象化をしていて、型制約を利用することで、ライフタイムやスレッド安全性をコンパイラレベルで保証しています。

いろいろと工夫があるんですが、タスク生成の部分だけ詳しく見ていきたいと思います。コードはこんな感じになっていて、funcというもので渡されるのがエントリの関数なんですが、FnOnceという型制約を付けることで、この中で複数回呼ばれないことを保証しています。TArgが引数でTRetが返り値ですが、Sendが制約として付いているのでタスクが終了しても引数や返り値が解放されないことを、static制約で保証しています。