A Framework for Easily and Efficiently
Extending Operating Systems
OSの機能拡張を容易にかつ効率よく
行なうための枠組
益田研究室 修士2年
光来健一
拡張可能OS
• OSの拡張に対する要求が高まっている
– 機能拡張
• 新しいネットワークプロトコルを追加する
例: IPv6
– 性能向上
• データベース専用のファイルシステムを使う
例: ファイルキャッシュのポリシにLRUを使わない
• 拡張可能OSが研究されている
– OSを拡張するためのプログラム(拡張モジュール)を
動的に追加できる
fail‐safe機構
• 拡張モジュールのエラーからOSを守る必
要がある
– 拡張モジュールは意図しない動作をするかも
しれない
• fail-safe機構の役割
– 拡張モジュールのエラーを検出する
– エラーの検出された拡張モジュールをOSから
安全に切り離す
従来のアプローチの問題点
• fail-safe機構は性能を犠牲にするので、両
者のトレードオフを取るのは難しい
– 拡張モジュールをloadable kernel moduleとして
作る
– 拡張モジュールをユーザプロセスとして作る
(Mach[Accetta et al.86])
– 拡張モジュールにload/store/jumpのアドレスを
検査するコードを挿入する
(VINO[Selzer et al.96])
fail‐safe機構に関する考察
• 常に完全なfail-safe機構が必要なわけで
はない
– 保護レベルは段階的に変えられた方がよい
例1.拡張モジュールの使用
• 不安定な場合は必要な保護をして使う
• 安定している場合は保護をせずに使う
例2.拡張モジュールの開発
1. デバッグ時には十分に保護する
2. βテスト時には保護を弱めて性能を良くする
3. リリース時には保護なしで動かせるようにする
多段階保護機構の提案
• 拡張モジュールを様々な保護レベルでOS
に組み込むことができる
– 安定度に応じて性能とfail-safeの能力のトレー
ドオフを取ることができる
保護レベル
高
低
不安定な拡張モジュール
やや不安定な拡張モジュール
安定な拡張モジュール
カーネル
性能
悪
カーネル
カーネル
良
システム構成
• 多段階保護機構を実現す
るシステム
拡張モジュール
– 保護マネージャ
• fail-safe機構を実現する
• 拡張モジュールとリンクされる
ライブラリ
• 複数用意されている
• それぞれが様々な保護レベル
を提供する
– 適切な保護マネージャを選
ぶことができる
保護マネージャ
カーネル
保護マネージャ
• 拡張モジュールとカーネ
ルの間のゲートウェイの
役割を果たす
– カーネルからのアップ
コールを中継する
– 拡張モジュールにカーネ
ルデータを安全に操作さ
せる
拡張モジュール
カーネルデータ
の操作
コールバック
保護マネージャ
システム
コール
アップコール
カーネル
保護レベルの変更
• 保護レベルの変更は保護マネージャの交換に
よって行なう
– 拡張モジュールのソースコードを変更したり、再コン
パイルしたりする必要はない
高
保護マネージャ1
拡張モジュール
保護レベル
保護マネージャ2
保護マネージャ3
低
共通のAPI
• すべての保護マネージャが共通のAPIを提供す
ることで交換を容易にする
– それぞれの保護マネージャの実装の違いを吸収する
• APIの種類
– コールバックのためのAPI
• カーネルからのアップコールによって呼び出される
– カーネルデータをアクセスするためのAPI
• 抽象度の高いデータ構造を見せる
様々な保護レベルの実現
• 保護マネージャは以下の保護技術を組み
合わせて様々な保護レベルを提供する
– 不正メモリアクセスの検出
• 拡張モジュールをユーザ空間に配置するかどうか
• カーネルデータのあるメモリを保護するかどうか
• カーネルデータを複製・検査するかどうか
– デッドロックの検出
• どのくらいの頻度でデッドロックの検査をするか
保護技術の組合せの例
(a)最大の保護レベル
直接
(b)中間の保護レベル
拡張
モジュール
API
拡張
モジュール
保護
マネージャ1
複製
保護
マネージャ2
カーネル
データ
カーネル
•ユーザ空間
•メモリ保護
•カーネルデータ複製
(c)最小の保護レベル
API
カーネル
データ
カーネル
カ
ー
ネ
ル
拡張
モジュール
保護
マネージャ3
•ユーザ空間
•カーネル空間
カーネルによるエラー回復
• 拡張モジュールのエラーを検出したら、
カーネルからエラーの影響を取り除く
– 不正メモリアクセスを検出した場合
• 以後そのモジュールを参照しないようにする
• ログを元に安定な状態に戻す
– カーネルの状態を不安定にする操作についてはログを
とっておく
– デッドロックを検出した場合
• wait-for-graphのループを破壊する
実験
• 多段階保護機構を実現するシステムCAPELAを
NetBSDをベースにして実装した
• 実験の目的
– 保護レベルに応じて性能が良くなることの確認
– 最大の保護レベルのオーバヘッドの測定
– APIを共通にすることによるオーバヘッドの測定
• 実験環境
– PC(PentiumII 400MHz) 2台
– 10Mbpsイーサネット
実験対象
• 対象
– ファイルシステム: MFS(Memory File System)、NFS
• 64KBのファイルのコピーに要する時間を測定
– ネットワーク・サブシステム: UDP、TCP
• 往復のレイテンシとスループットを測定
• 表の5つの保護レベルとカーネルに直接作り込
んだものについて実験した
1st
メモリ保護
カーネルデータの複製
アドレス空間の切替え
2nd 3rd
4th
5th
:読み出し専用
にして保護
結果: ファイルシステム
(コピーに要する時間)
– MFS: 210%
– NFS: 70%
50
40
Time (ms)
• 最大の保護レベルの
オーバヘッド
MFS
40
30
23.8
19.9
20
12.3 11.8
10
0
• APIを共通にすること
によるオーバヘッド
600
Time (ms)
– MFS: 3.7%
– NFS: 1.4%
38.1
1st
2nd
490
500
3rd
5th
hand
315
288
284
4th
5th
hand
NFS
361
400
4th
200
0
1st
2nd
3rd
結果: ネットワーク・サブシステム
(往復のレイテンシ)
– UDP: 180%
– TCP: 220%
1000
Latency (us)
• 最大の保護レベルの
オーバヘッド
800
493 459
600
400
294
263
5th
hand
440
428
5th
hand
200
0
• APIを共通にすること
によるオーバヘッド
1st
1500
Latency (us)
– UDP: 12%
– TCP: 2.8%
UDP
829 821
2nd
3rd
1410
TCP
1198
1000
4th
684 610
500
0
1st
2nd
3rd
4th
結果: ネットワーク・サブシステム
(スループット)
• 最大の保護レベルの
オーバヘッド
• APIを共通にすること
によるオーバヘッド
– TCP: 1.3%
Throughput (Mbps)
– TCP: 10%
TCP
8
6.38 6.44
6.91 6.96
7.04 7.13
6
4
2
0
1st
2nd
3rd
4th
5th
hand
ソースコード変換による性能向上
• OpenC++[Chiba95]を使いソースコード変換をした
– APIを共通にするためのオーバヘッドを減らす
• カーネルが使うデータ構造と拡張モジュールが使うデータ構造
の変換など
– 変換前の約半分
UDPの往復のレイテンシ
400
Latency (us)
• UDPでは変換した後
のオーバヘッドは6.1%
に抑えられる
300
294
279
263
5th
translated
hand
200
100
0
関連研究
• Chorus[Rozier et al.88]
– ユーザレベルサーバをカーネルに入れること
ができる
– カーネルに入れた時の性能が不十分
• ファイルの読み出しで80%のオーバヘッド
• SPIN[Bershad et al.95]
– 型安全な言語Modula-3を使って拡張モジュー
ルを記述する
まとめ
• 多段階保護機構を提案した
– 拡張モジュールを変更なしに様々な保護レベ
ルでOSに組み込める
• CAPELAを実装し、実験によって多段階保
護機構の有用性を確かめた
– 不安定な時は許容範囲内のオーバヘッドで十
分な保護ができる
– 安定している時はカーネルに作り込んだもの
に十分近い性能が得られる
今後の課題
• カーネルレベルでも様々な保護レベルを提供す
る
– タイミング依存のエラーの検出など
• いつ保護レベルを変えるべきかの指針を示す
– モジュールの安定度に応じて自動的に保護レベルを
変える
• 拡張モジュール間のやりとりを効率よくできるよう
にする
– OSの拡張モジュールという特徴を活かす
ダウンロード

ppt - KSL