新規ファイルシステムの開発における ＯＳの多段階保護機構の必要性 光来 健一* 千葉 滋** 益田 隆司* * 東京大学大学院 理学系研究科 情報科学専攻 ** 筑波大学 電子・情報工学系 東京大学の光来 新規ファイルシステムの開発における OS の多段階保護機構の必要性について発表

拡張しやすいＯＳ ＯＳを拡張するためのモジュールをＯＳに追加できる 拡張によって不安定にならない 拡張可能なＯＳ（ＳＰＩＮ、Ｅｘｏｋｅｒｎｅｌ） 拡張によって不安定にならない モジュールのバグからＯＳを守る 最近、ExokernelやSPINといった拡張可能なOSの研究が盛ん OSが拡張可能であれば、柔軟性を高めることができ、OS全体の性能をよくすることができる このようなOSでは、OSを拡張するためのモジュールをOSに追加することによってOSを拡張できる 例：ベンダがデバイスドライバやファイルシステムなど改良した時に、もし動的にモジュールを追加できるなら、OS全部を入れ換えたり、OSを再コンパイルしたりせず、今動いているOSを動かしたままでそれらを組み込める これは便利 しかし拡張したことによってOSが不安定になっては意味がない 例：いくら性能がよくなったデバイスドライバが提供されても、そのバグのせいでOS全体が落ちて、編集中のファイルが消えてしまったら困る そういう時に落ちるのはバグのあったモジュールだけならうれしい このようにモジュールのバグからOSを守れるなら、それは拡張しやすいOS 拡張しやすいOSを作る上では、OSの安定性を保つために保護機構が必要になる 保護機構が必要 SWoPP '97

マイクロカーネルの保護機構 マイクロカーネルでＯＳの安定性を保つのは比較的容易である 保護機構のオーバヘッドが大きく実行効率が悪い 拡張モジュールをユーザプロセスにする 保護機構のオーバヘッドが大きく実行効率が悪い システムコールが増える マイクロカーネルの保護機構のようなものを使ってOSの安定性を保つのは比較的簡単 そのためにはOSを拡張するためのモジュールをユーザプロセスにして、カーネルや他のユーザプロセスから切り離してしまえばよい しかしユーザプロセスは信頼できないアプリケーションからOSを守る役目も持っているので、システムコールなどの保護機構のオーバヘッドが大きすぎて、実行効率が非常に悪くなる いくら十分な保護機構があっても、実行効率が悪いのでは実用的には使えない そこで実行効率についても考慮した保護機構が必要になる 保護機構 ｖｓ 実行効率 SWoPP '97

多段階保護機構の提案 拡張モジュールの安定度に合わせて段階的に保護の強さを変える 各段階で同じインタフェースを提供 安定していれば実行効率を優先する 不安定ならば保護を優先する 保護の強さが一種類では不十分である 各段階で同じインタフェースを提供 ソースコードの変更は不要である そこで我々は多段階保護機構を提案 多段階保護機構はOSを拡張するためのモジュールの安定度に合わせて、段階的に保護の強さを変えることができる モジュールが安定していれば、実行効率を優先するために保護を弱めることができる 逆に不安定ならば、実行効率を犠牲にして保護を優先することができる 保護の強さを多段階用意するのは、モジュールごとに安定度は異なるので、一種類用意しただけではある特定の安定度をもったモジュールにしか適さず十分ではないから この保護機構は各段階で同じインタフェースを提供しているので、保護の強さを変えてもユーザはソースコードを変更する必要はない これは簡単に保護の強さを変えられるようにするために非常に重要 SWoPP '97

なぜ多段階保護機構か？ ＯＳを拡張するモジュールには完全な保護機構は必要ない 拡張モジュールに悪意はない モジュールのバグからＯＳを守ればよい 保護の完全性を緩めた弱い保護を使い、実行効率を優先させたいこともある 安定しているモジュールでは保護を弱くしたい なぜ多段階保護機構を使うのか 一つはOSを拡張するモジュールにはマイクロカーネルのような完全な保護機構は必要ないから 拡張のためのモジュールは普通悪意をもって作られているわけではないので、信頼することができる だからモジュールのバグからOSを守ることができさえすればよい もう一つの理由は、完全性を緩めた、我々が弱い保護と呼んでいる保護を使って実行効率をよくしたいこともあること 例：安定しているドライバなどには非常に弱い保護をかけるだけにするか、もしくは全く保護をかけないようにして実行効率をよくしたい こういう時に保護を弱められるなら、モジュールとカーネルの間の通信をシステムコールを使って実装するのではなく、手続き呼び出しを使って効率よく実装できるかもしれない そして保護の完全性に伴うオーバヘッドを減らすことができる SWoPP '97

多段階保護機構の設計 ファイルシステムのための多段階保護機構を設計した ５段階の強さの保護を用意した ソースコードの変更なしで保護の強さを変えられる 保護の強さの変更は再コンパイルまたは再リンクで行なう 我々はこの多段階保護機構をファイルシステムのために設計した ここでは５段階の強さの保護を用意している 保護の強さを変えるのにはソースコードを変更する必要はない 保護の強さを変えるには、インクルードするファイルやリンクするライブラリを変えることによって行なうので、再コンパイルまたは再リンクだけで済む SWoPP '97

ファイルシステムでの応用例 ファイルシステムの開発の進み具合に応じて保護の強さを変える 提供された不安定かもしれないファイルシステムを使う 開発者が性能のよいファイルシステムを簡単に作ることができる 提供された不安定かもしれないファイルシステムを使う ユーザが安全に新しいファイルシステムを使うことができる 各段階について説明する前に、多段階保護機構を使ったファイルシステムでどのような応用例が考えられるかを説明する ファイルシステムの開発をする時に、最初はバグが多いので強い保護をかけて開発やデバッグをする バグが減って安定するにつれて保護を弱めていき、最終的に完成したら保護をなくして最大限、実行効率をよくする このように開発者が性能のよいファイルシステムを簡単に作ることができる ベンダが提供しているファイルシステムが不安定なことがあるかもしれない その場合には、最初は強めの保護をかけて使い、安定しているようなら保護を弱めて実行効率をよくできる 不安定ならOSから安全に切り離すことができる このようにユーザが安全に新しいファイルシステムを使ってみることができる SWoPP '97

各段階の位置づけ ＯＳの安定度 第０段階 ソースコードの変更不要 第１段階 第５段階 作り込み ＯＳの実行効率 SWoPP '97 各段階の位置づけについて説明 第０段階はOSの安定度は最大だが実行効率は最も悪い 作り込みは安定度は最低だが実行効率は最もよい その間に第１段階から第５段階があり、ここの間ではソースコードの変更は不要 作り込み ＯＳの実行効率 SWoPP '97

第０段階 実行効率が悪いので実装していない 第１段階～第４段階の基本 マイクロカーネル アーキテクチャと 同等 アプリ ファイル ケーション システム マイクロカーネル アーキテクチャと 同等 システム コール アップ コール システム コール 第1段階から第5段階までの5段階の保護の実現方法について説明 その前に実行効率が非常に悪いので実装はしていないが、第1段階から第4段階の基本となっている第0段階について説明 アプリケーション(例：エディタ)がファイルに関するシステムコール(例：read)を発行すると、カーネルはユーザレベルのファイルシステムにアップコールする このファイルシステムはシステムコールを使ってカーネルのデータを読み書きしながら、ファイルシステムとして必要な処理を行なう これはマイクロカーネルアーキテクチャと同じで、安定性は保てるが非常に実行効率が悪くなる カーネル データ カーネル SWoPP '97

第１段階（１） カーネルデータを共有メモリ上に置く 実行効率が良くなり、ポインタも扱いやすい ファイル システム アプリ ケーション ライブラリ アプリ ケーション カーネル データ カーネルとファイルシステムの間に共有メモリを張り、カーネルのデータをその上におく こうすることによって、ファイルシステムはシステムコールを使わずにカーネルのデータを読み書きできるようになる これで実行効率が良くなるのはもちろん、カーネルのデータ構造で非常によく使われているポインタも扱いやすくなる システム コール アップ コール 共有 メモリ カーネル SWoPP '97

第１段階（２） 共有メモリに直接アクセスするのは危険 ライブラリはどのようにカーネルデータを保護するか？ カーネルデータを破壊するかも 共有メモリへのアクセスはライブラリが隠蔽 ライブラリはどのようにカーネルデータを保護するか？ 共有メモリを保護する カーネルデータをコピーする ただし、直接ファイルシステムが共有メモリにアクセスすると、誤ってその上にあるデータを破壊してしまうかもしれず危険 そこで共有メモリへのアクセスはライブラリが隠蔽し、ファイルシステムはそのライブラリを通して共有メモリにアクセスする それでもファイルシステムのバグによって共有メモリ上のカーネルデータを破壊するかもしれない そこでライブラリは共有メモリの保護とカーネルデータのコピーによって共有メモリ上のカーネルデータを保護する これからこの２つについて詳しく見ていく SWoPP '97

共有メモリの保護 ライブラリの外では共有メモリをアンマップ アクセス可 悪意ある アクセス不可 ファイルシステム からは守れない 正規の手続き ファイル システム ライブラリ アクセス可 アクセス不可 悪意ある ファイルシステム からは守れない ライブラリの中では共有メモリをマップするが、外に出るとアンマップする ライブラリの中からは自由にアクセスできるが、ライブラリの外にあるファイルシステムからはアクセスできない しかし、ライブラリとアドレス空間が同じなので、共有メモリのIDさえ手に入れることができれば、共有メモリをマップしてアクセスできる だから悪意あるファイルシステムからは守ることはできない しかし、悪意がなければ偶然IDを手に入れて偶然マップすることはまずない この保護のしかたを変えることで保護の強さを変えることができる 共有 メモリ カーネル SWoPP '97

カーネルデータのコピー ライブラリの外では共有メモリ上のカーネルデータをコピーしたものにアクセス ファイル システム カーネル ライブラリ ライブラリの中では直接共有メモリにアクセスするが、外のファイルシステムは共有メモリのカーネルデータのコピーにアクセスする ただコピーするのではなく、見せる必要がないものは見せないし、ポインタはつけかえる これによってコピーしたカーネルデータの中のポインタは共有メモリを差さないので、間違いが起こる可能性も低くなる しかし、コピーにアクセスせずに直接共有メモリにアクセスすることは可能だからこれも悪意あるファイルシステムからは守れない このコピーをするかどうかで保護の強さを変えることができる 共有 メモリ カーネル SWoPP '97

第１段階～第４段階 第１段階～第４段階の違いは以下の通り SWoPP '97 今述べたような共有メモリ上のカーネルデータの保護のしかたの違いが第1段階から第4段階の違い 第1段階では、ライブラリの中に入った時だけ共有メモリをマップし、ライブラリの外に出たら、不正にデータを読み書きされないようにアンマップ 第 2 段階ではライブラリの外ではリードオンリーにすることによって共有メモリを保護するので、ファイルシステムがデータを読むことはできる その分保護は弱まるが、変更する必要のないデータはコピーせずに、直接共有メモリを参照できるので、実行効率をよくできる 第3段階では共有メモリに対する保護はかけないが、ファイルシステムはコピーにアクセスするので、多少は安全 第4段階では共有メモリのアクセスには全く保護がないので、実行効率がよくなる SWoPP '97

第５段階 ファイルシステムをカーネルに組み込む ソースコードを変えないためのオーバヘッドは残る モノリシックカーネル とほぼ同等 アプリ ケーション モノリシックカーネル とほぼ同等 システム コール 第5段階ではこれまでユーザレベルにあったファイルシステムをカーネルに組み込む これによって UNIX のようなモノリシックカーネルとほぼ同等になり、安全性は失われるが、非常に実行効率がよくなる ただし、インタフェースを共通にしているので、そのオーバヘッドが残る 例：関数呼び出しのオーバヘッドなど インライン展開などのコンパイラ技術を使えば減らすことができる ファイル システム カーネル SWoPP '97

多段階保護機構の実装 ファイルシステムのための多段階保護機構をNetBSDに実装した ２つのファイルシステムを作成・実験した 簡易RAMディスク 簡易NFS 我々はこの多段階保護機構をNetBSDに実装した このシステムの上で２つのファイルシステムを作った 一つはメモリ上にファイルシステムを作る簡単なRAMディスク もう一つはネットワーク上にサーバとクライアントがある簡単なNFS SWoPP '97

多段階保護機構のオーバヘッド測定 ブロックサイズを変えてファイルの転送時間を測定した 実験対象 実験環境 第１段階～第５段階のファイルシステム 多段階保護機構を使わず、カーネルに作り込んだファイルシステム 実験環境 SPARCstation 5 多段階保護機構のオーバヘッドを測定するために実験を行なった ２つのファイルシステムについて、ブロックサイズをいろいろと変えて64Kbyteのファイルの転送時間を測定した 測定は実装した５段階の強さの保護のそれぞれについてと、多段階保護機構を使わずに最初からカーネルに作り込んだものについて行なった この実験はSPARCstation 5で行なった SWoPP '97

実験結果（簡易RAMディスク） 第１段階：作り込み＝１５：１ 第１段階 第２段階 第３段階 第４段階 第５段階 SWoPP '97 作り込みは第5段階とほぼ重なるので表示していない 横軸がブロックサイズ、縦軸が転送時間 一番保護の強い第1段階が一番時間がかかっていて、保護を弱めるにつれて転送時間が短くなっている 一番保護の強い第1段階はカーネルに作り込んだものに比べて、15倍程度の時間がかかっている ただし、ブロックサイズが非常に小さい時には、第1段階から第4段階まではかなり時間がかかっている 第３段階 第４段階 第５段階 SWoPP '97

実験結果（簡易NFS） 第１段階：作り込み＝５：１ 第１段階 第２段階 第３段階 第４段階 第５段階 SWoPP '97 作り込みは第5段階とほぼ重なるので表示していない 簡易RAMディスクの結果とほぼ同じ 一番保護の強い第1段階はカーネルに作り込んだものに比べて、5倍程度で済んでいる 第４段階 第５段階 SWoPP '97

第５段階と作り込みの性能差 １５％増 ７％増 ６４Ｋｂｙｔｅのファイル転送時間 （ブロックサイズ ６４Ｋｂｙｔｅ） 簡易ＲＡＭディスク 簡易ＮＦＳ １５％増 ７％増 この２つのグラフは簡易RAMディスクと簡易NFSについて、一番保護の弱い第5段階と、最初からカーネルに作り込んだものとの性能を比較 第5段階はカーネルに作り込んだものと比べて、簡易RAMディスクで15%、簡易NFSで7%程度のオーバヘッドがかかっている 作り込み 第５段階 作り込み 第５段階 SWoPP '97

考察（１） 保護を弱めると実行効率が改善される 最も保護の弱い第５段階は作り込みに近い性能を示す 最終的に性能のよいファイルシステムを作成可能 この実験結果から、保護を弱めるとその分実行効率が改善されていることが分かる 最も保護の弱い第5段階は、最初からカーネルに作り込んだものに近い性能を示している これより、多段階保護機構を使って作成したファイルシステムは最終的には、性能のよいファイルシステムにすることができることが分かる SWoPP '97

考察（２） かなり強い保護をかけてもオーバヘッドはそれほど大きくない カーネルとの通信が頻繁に起こるとオーバヘッドが大きくなる ＯＳの安定性を実用的なオーバヘッドで保てる かなり強い保護をかけても、オーバヘッドはそれほど大きくない ただし、ファイルシステムの処理量に比べてカーネルとの通信が多い時には、ファイルシステムがユーザレベルにある第１段階から第４段階ではオーバヘッドが大きくなっている 例えば、簡易RAMディスクはファイルシステム自体の処理量が非常に少なく、カーネルとの通信時間が相対的に大きくなるために、第１段階は作り込みの15倍とかなり大きいオーバヘッドがかかっている またブロックサイズが非常に小さい時にも、アップコールが頻繁に起こるので、オーバヘッドが大きくなっている しかし一般には、OSの安定性を実用的なオーバヘッドで保てている SWoPP '97

関連研究 Ｍａｃｈ ［Accetta 86］ ＳＰＩＮ ［Bershad 95］ ＶＩＮＯ ［Seltzer 94］ モジュールはユーザプロセスで作成 ＳＰＩＮ ［Bershad 95］ モジュールは型安全なＭｏｄｕｌａ-３で書かれる ＶＩＮＯ ［Seltzer 94］ Ｓｏｆｔｗａｒｅ Ｆａｕｌｔ Ｉｓｏｌａｔｉｏｎでモジュールの安全性を保つ マイクロカーネルであるMachではOSを拡張するモジュールはユーザプロセスで作られる これは第0段階と同じで、OSの安定性は保たれるが、実行効率が非常に悪くなる 拡張可能OSであるSPINでは、モジュールは型安全な言語であるModula-3で書かれる これによってポインタがおかしな所を指すということはなくなるが、逆にそれが制約となってプログラムが書き難くなる可能性がある VINOではSoftware Fault Isolationを使ってモジュールの安定性を保っている Software Fault Isolationとは、プログラムの中のload/storeやジャンプ命令の前にその正しさを検査するコードを挿入する技術 これらのアプローチはどれも、最適な一種類の強さの保護のみを提供しようとしているにすぎない 最適な一種類の強さの保護のみ提供 SWoPP '97

まとめ 多段階保護機構を提案した ファイルシステムのための多段階保護機構を実装した 実験によって多段階保護機構の有用性を示した 拡張によってＯＳが不安定にならないように、段階的に保護の強さを変えられる ファイルシステムのための多段階保護機構を実装した 実験によって多段階保護機構の有用性を示した 最終的に作り込みに近い性能が得られる 本発表では多段階保護機構を提案した 多段階保護機構では、拡張によってOSが不安定にならないように段階的に保護の強さを変えながら、実行効率をよくすることができる そしてファイルシステムのための多段階保護機構をNetBSDに実装し、実験によって、多段階保護機構の有用性を示した SWoPP '97

今後の課題 多段階保護機構は一般的な機構なので、他のサブシステムに対しても実装する 多段階保護機構をアプリケーションのプラグインなどに幅広く利用できるようにする 今回はファイルシステムに限定して多段階保護機構を導入したが、多段階保護機構は一般的な機構なので、ファイルシステムに特化したものではない 今後は、ファイルシステム以外のサブシステムにも導入し、より汎用的な実装にしていくつもり さらには、アプリケーションのプラグインなどに幅広く使えるようにしたいと考えている SWoPP '97