![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
[[FrontPage]] > [[adv_system]] **3. Exokernel のデザイン [#xcebc1a4] ***exokernelの挑戦 [#e90fbfda] -libOS が物理リソースを扱うという点において、最大限の自由を提供すること。その際に、他の者から守りつつ、自由を提供する。 --他の者から守るとは、プログラミングのエラーがある libOS が、他の libOS に影響を及ぼさないようにすること。 -この目標を達成すべく、exokernel は管理から、低レベルインタフェースまで、保護（protection）を分離させている。 --なんだろ？？？ -管理から保護を分離させるために、3つの重要なタスクがある ++リソースの所持者を追跡すること ++全てのリソース使用や、バインディングポイント（binding points）をガードすることで、保護を保証すること ++リソースへのアクセスを破棄（revoking）すること -これらのタスクを実現するために、exokernel は 3つの技術を使っている。 ++secure bindings: libOS は物理リソースに対して、セキュアなバインド（securely bind）が可能である。 ++visible rebocation: libOS が resource revocation protocol に参加できる。 ++abort protocol: exokernel が使う。非協力的な libOS が行っているセキュアバインドを強制的にぶち壊せる。 このセクションでは exokernel アーキテクチャの設計原則を羅列している。そして先ほどの 3つの技術（管理と保護を分離するために使うもの）の詳細について議論している。 ***デザインの原則 [#mcbfd082] -exokernel は libOS のインタフェース（claim（要求？）, release（解放？）, 物理リソースの利用）について細かく指定している。 このセクションではいくつかの原則、つまり我々が libOS に最大限の操作性を与えるため exokernel のインタフェースをどうデザインしたか紹介する。 ***Security expose hardware [#e96dd46c] -exokernel で中心となる原理は、カーネルがセキュアな低レベルプリミティブを提供すべきということ。 --低レベルプリミティブってのは、可能な限り全ての物理リソースにアクセスできる物（物なのか？）のこと。 -exokernel はだから、特権命令、DMA のケーパビリティ、物理リソースを安全に export することを頑張った。 --export されているリソースは、これらの基本的なハードウェアです。 ---物理メモリ ---CPU ---ディスクメモリ？ ---TLB(translation look-aside buffer) ---アドレスコンテキスト識別子（addressing context identifiers） --この原則は、あまり触れられない（to less tangible）マシンの資源を拡張する。 ---割り込み ---例外 ---クロスドメインコール（cross-domain calls） exokernel はこれらのイベントに対して、高レベルな抽象化を行ってはならない（例えば Unix のシグナルとか RPC のようなもの）。柔軟性を向上させるには、ほとんどの物理リソースがきちんと再分割されなければならない。 -以下は libOS から可視でなければならず、さらに置き換えることも出来ないとダメ。どんな特権状態のコプロセッサ状態であっても。（意味わからず、直訳にすらならん） --数値 --フォーマット --TLB の現在のセット -原文: The number, format, and current set of TLB mappings should be visible to and replaceable by library operating systems, as should any “privileged”co-processor state. exokernel は libOS に特権命令を export しなければならない。これは libOS が従来の OS の抽象化を実装するために使う。 -従来の抽象化: プロセス、アドレス空間など -どの操作も、あらゆる資源の所持者を確認するシステムコールとしてカプセル化できる。 ---- ネガティブに言ってしまうと、この原則はつまり exokernel が「リソース管理をさぼりたい」ってことなのだ。 -exokernel は、保護が要求された部分のリソース、これだけを管理すべき。 -例えば…割り当ての管理、破棄、所持権を与えるなど この原則の動機は我々の信念である「分散で、アプリケーション特有のリソース管理は、効果的で柔軟性のあるシステムを構築するのにベストである」ということ。（直訳…） この後にある原則は、この目標を達成するための詳細を扱っている。 ***Expose allocation [#h839756f] -exokernel では libOS が特定の物理リソースを要求しても良い。 --例えば、libOS は特定の物理ページ（メモリのかな？）を要求できるし、working set というので、ページ間でのキャッシュの衝突を減らすこともできる。（参考文献 29） -さらに、リソースは暗黙のうちに割り当てられるべきではない。 --libOS は各割り当ての決定に、関与（？ participate と書いてある）すべき。 次の原則ではこの関与（participation）の効用について補足している。 ***Expose Names [#kdd87e7b] -exokernel は物理名（physical names）を export すべき。 -物理名は有能。 --理由は、仮想的な名前から物理的な名前に変換するために必要な、他のレベル（名前解決用、名前の変換レイヤってことか？）を除去できるから。 -物理名はリソースの属性を便利に符号化できる。 --例えば、physically-indexed ダイレクトマップキャッシュを持つシステムだとして、物理ページ（例えば、ページ番号）から、どのページと衝突するかわかる。 -exokernel は book-keeping data（例えば、freelists、ディスクアームの位置、TLB のキャッシュしたエントリ）も export すべき。 --アプリケーションが割り当て要求を調整できるように。 ***Expose Revocation [#z6506d46] -exokernel は可視状態のリソースの破棄プロトコル（visible resource revocation protocol）を役立てるべき。 --上位互換性のある libOS（well-behaved lib...）が効果的にアプリケーションレベルでリソース管理を出来るできるように。 -可視状態の破棄（visible revocation）は物理名を使うのを容易にし、libOS が 特定のリソースのどのインスタンスを放棄すればよいのか選ぶのを許可する。（意味不明） -原文: Visible revocation allows physical names to be used easily and permits library operating systems to choose which instance of a specific resource to relinquish. ---- ***Policy [#ne67dd11] -exokernel はポリシーによる判定を libOS に手渡す。 --リソースのこのコントロールを使うことで、アプリケーションまたは強調しあうアプリケーションの集合は、これらのリソースをどう使うのがベストなのか、決定を下すことができる。 -しかしどのシステムにおいても、exokernel は libOS 同士のかち合いを調停するために、ポリシーを include すべき。 --exokernel は、異なるアプリケーションの絶対的な重要度（absolute importance）を決定しなければならない。リソースのシェアなどで。 --この状況は、今までのカーネルと何も変わりない。 -OS のアーキテクチャによって決定するより、環境によって決定した方が適した機構である。 --例えば、リソースの管理を libOS に譲渡している間、exokernel はこれらリソースの割り当てや破棄を制御できる。 -割り当て要求を与えることや、またどのアプリケーションから破棄するかを決めることで、exokernel は従来のストレージのパーティション（クオータ(quota)や、予約(reservation)スキーム）を強制できる。 -ポリシーの衝突は、結局はリソース割り当ての決定ということである。 --シークタイム、物理メモリ、ディスクブロックの割り当てなど --exokernel は同じような方法でそれらを扱うだけ。 ***3.2 Secure Bindings [#t056086d] -リソースをセキュアにを分割するのは、exokernel の基本的なタスクの一つ。 --保護を実装するためには、exokernel は libOS に secure binding を使ってもらう。 -secure binding とは、保護の機構である。 --リソースの実際の利用から、分断された認証（decoupled authorization）である。 -secure binding は以下の 2点において、実行速度を改善する。 ++保護のチェックが secure binding を執行する（enforce）ことに含まれている。secure binding はいくつかの単純な命令で表せる。そのためカーネルあるいはハードウェアは、素早く実装できる。 ++secure binding が認証を実行するのは bind 時だけである。これにより管理を保護から切り離すことができる。 -アプリケーションレベルのソフトウェアは、多くのリソースの複雑なセマンティクス（ネットワーク接続など）について責任を持つ。 -bind 時まで、これらのセマンティクスを理解する必要性を隔離する（isolation）ことで、カーネルはそれらを理解することなく、アクセス時のアクセスチェックを効果的に実装できる。 単純に言えば、secure binding は、カーネルがリソースの保護について考えなくて良いようにするものである。 ---- -操作上、secure binding のサポートが必要とするある要求は、プリミティブ（アプリケーションレベルのソフトウェアが、素早く保護をチェックするのに使える）の集合である。 -プリミティブは、ハードウェアで実装しても、ソフトウェアで実装しても良い。 --単純なハードウェア secure binding は TLB エントリである。 ---TLB のフォルトが起きたとき、libOS のページテーブルにあるマッピング（仮想アドレスから物理アドレスに変換する複雑なマッピング）が実行される。そしてカーネルに読み込まれて（bind）、何度も使われる（access time）。 --他の例としては、パケットフィルタ（文献 37）である。これはカーネルにダウンロードされ（bind time）、そして、どのアプリケーションのためのパケットなのか決定するため、入力されるパケットすべてに対して実行すること（access time）を、記述できる。 ---パケットフィルタがないと、カーネルは各アプリケーションやネットワークサーバに、これは誰のためのパケットなのか？を決定するためのクエリを要求するだろう。 -認証や管理（コネクションや、セッションや、再送の管理など）から隔離された保護（パケットは誰のなのか決定すること）によって、とても高速なネットワークの多重化が可能である。 --さらにアプリケーションレベルの柔軟性をサポートしたままで。 ---- -secure binding の実装のために、三つの基本的な技術を使った。 --ハードウェアの機構、ソフトウェアによるキャッシュ、アプリケーションコードのダウンロード -特殊なハードウェアのサポートによって、secure binding は低レベルの保護命令として表せる。 --後の命令で、高レベルの認証情報なしで、効果的にチェックすることが出来る。 --例えば、ファイルサーバがデータをメモリにバッファリングして、認証されたアプリケーションに物理メモリへのケーパビリティを渡すことで、アクセス権を与える。 ---このとき、exokernel はファイルシステムの認証機構の情報を何も必要とせず、ケーパビリティのチェックを実施するだろう。 --他の例としては、いくつかの Silicon Graphics のフレームバッファ（ハードウェア）が、所持権タグ（ownership tag）を各ピクセルと関連づける。 ---window manager で使える。libOS とフレームバッファの一部を結びつけるのに使える。 ---アプリケーションはフレームバッファに直接アクセスできる。なぜなら I/O を起こすときに、ハードウェアが所持権タグをチェックしているから。 -secure binding は exokernel にキャッシュされる。 --具体的には、ハードウェア TLB に載らないアドレスをキャッシュするために exokernel は large software TLB（文献 7, 28）を使う。 --software TLB はよく使われる secure binding のキャッシュと見なせる。 -secure binding はカーネルにダウンロードされるコードによる実装も出来る。 --このコードは色々な要因で起動される。 ---あらゆるリソースへのアクセス、または所持権決定するためのイベント、カーネルが実行すべき行動である。 -カーネルにダウンロードされたコードは、コントロールのアプリケーションスレッド（？ application thread of control）がカーネルイベントで即時に実行されるのを許す。（直訳） --ダウンロードされたコードの利点は、潜在的に高コストな crossings を避けることができ、アプリケーション自身がスケジュールされなくてもコードが実行できること。（直訳） -type-safe languages（文献 9, 42）、インタープリタ、サンドボックス（文献 52）は、信用ならないコードを安全に実行するのに使える。 我々は、以下の 3つの技術の例を見せる。そして、どうやって secure binging を物理メモリとネットワークデバイスの多重化に適用するか議論する。 ***Multiplexing Physical Memory [#ecc93d46] -プロトタイプでの secure binding は、self-authenticating capabilities（文献 12）と、アドレス変換ハードウェアで実現されている。 --libOS が物理メモリページを割り当てたとき、exokernel は所持者を記録して、read-write ケーパビリティを libOS に指定することで、そのページのための secure binding を作る。 --ページの所持者は、ページに関連したケーパビリティを変更、あるいはページを解除（deallocate）する権限を持っている。 -保護を保証するため、libOS が要求するアクセスを表現したケーパビリティを要求することで、物理メモリページに対するあらゆるアクセスをガードする。らしい？？ --もしケーパビリティが十分でなければ、アクセス拒否される。 --典型的にはプロセッサは TLB を持っている。exokernel は、libOS が新しい物理-仮想アドレスのマッピングを追加しようとしたときに、メモリケーパビリティをチェックしなければならない。 -数を減らすことで libOS の性能を向上させるためには、secure binding を確立しなければならない？？？ --exokernel は large software TLB に仮想-物理アドレスのマッピングをキャッシュするだろう。 -もし基本的なハードウェアがページテーブルのインタフェースを決めていたら、exokernel は TLB よりむしろページテーブルをガードしなければならない。 --しかしながら secure memory binding をどうやって実装するのかという詳細は、アドレス変換ハードウェアの詳細に様々に依存する。 -基本的な信念は単純である。特権命令（TLB のロードや DMA）を exokernel がガードすることである。 --exokernel の原則である exposing kernel book-keeping によって命令することで、ページテーブルはアプリケーションにも見える（読み取り専用）。 -リソースを保護するためにケーパビリティを使うことで、カーネルの介在なしで、アプリケーションが他のアプリケーションにアクセス権を与えることができるようになる。 --アプリケーションは、リソースを簡単に共有するために well-known ケーパビリティを使える。 -secure binding をぶち壊すには、exokernel は関連したケーパビリティを変更して、リソースが自由になったとマークする必要がある。 --物理メモリの場合だと、exokernel は全ての TLB のマッピングと、あらゆる DMA のリクエストをフラッシュするだろう。 ***Multiplexing Network [#t3df709c] -ネットワークの多重化は挑戦だ。 --なぜならやってくるメッセージの中身に割り込んだり、受信者を特定するには、protocol-specific な知識が必要とされるから。 -ネットワークの多重化を解除する機能は、ソフトウェアあるいはハードウェアが提供できる。 --ハードウェアベースだと、アプリケーションの securely bind streams として、ATM の仮想サーキットを使う方法（文献 19）がある。 --ソフトウェアベースだと、パケットフィルタ（文献 37）が提供できる。 ---パケットフィルタは、アプリケーションコード（フィルタ）がカーネルにダウンロードされる secure binding の実装と見なせる。 -パケットの所持権を決定したくて、保護のチェックが要求されても、プロトコルの知識はアプリケーションしかしらない。 --パケットの所持権はカーネルが理解できる言語で表現される。 --fault isolation は慎重に言語を設計する（実行時に結合する）か、実行時にチェックする（めちゃくちゃなメモリへのアクセスや危ない命令から保護する）ことで保証できる。 -プロトタイプでは、パケットフィルタを使っている。 --なぜなら現在のネットワークの多重化を解除するための、ハードウェアの機構が提供されていないから。 -言語ベースのアプローチとして一つチャレンジしたのは、フィルタを早くすること。 ---従来はパケットフィルタは、インタープリタだった。それはカーネル内の多重化解除ルーチンより効率が悪い。 ---exokernel が使うパケットフィルタエンジンの区別する機能の一つを、実行時に機械語にコンパイルした。 ---ものすごいオーダーで実行速度が向上した（文献 22）。 -パケットフィルタを使用する問題点は、フィルタは嘘をつけないのと、許可したパケットは他のプロセス行きであること。 --単純なセキュリティの予防、例えば信用できるサーバからだけフィルタをインストールするのを許す、この問題について検討するのに使える。 ---悪意のあるプロセスは居ないと仮定したシステムで、我々の言語は十分単純。 ---到着したパケットが別のところに属することはできない、と保証するための新しいフィルタを静的にチェックすることによって、信頼されたサーバさえも回避できるかもしれない。 ---中央での認証を回避することにより、拡張性は増加する。 ---（全体的に意味不明） -外向きのメッセージに対して、ネットワークインタフェースを共有するのは簡単。 --メッセージは単にアプリケーションの空間から、送信バッファにコピーされるだけ。 --実際、特別なハードウェアの機能があれば、送信バッファは物理メモリページのように簡単に、アプリケーションの空間にマップ出来るだろう（文献 19）。 ***3.2.1 Downloading Code [#rcc31218] secure binding の実装に加えて、ダウンロードコードも実行速度の向上に使える。 -カーネルにダウンロードするコードは、2つの利点がある。 ++明らか。カーネルの干渉（crossing）を排除できる。 ++微妙。ダウンロードコードの実行時間は readily bounded （すぐに飽和する？？）（文献 18）から。 ---「制御された（tamed）」コードの非常に大切な点は、アプリケーションがスケジュールされていなくてもコードが実行できることである。 ---この分割によって、アプリケーション自身へのコンテキストスイッチングが実行不可能であったとしても、ダウンロードコードが実行される。 ---例えば、たった数マイクロ秒しか自由に計算できるプロセッサ時間がないときとか。 -パケットフィルタはこの機能の例である。 --なぜならパケットフィルタのルーチンは bounded で、カーネルはどのアプリケーションがスケジュールされているかに関係なくメッセージの多重化を解除するのに使う。 ---OS が潜在的なパケットの消費者をスケジュールするために、持っているであろうパケットフィルタなしで（文献 37）。 ---そして意味不明。 -Application-specific Safe Handlers（ASHs）はダウンロードコードのもっと面白い例。 --これらのアプリケーションハンドラは、メッセージプロセシングをするためにカーネルにダウンロードできる。 --ASH はパケットフィルタと関係していて、パケット受信者側で動く。 --ASH の重要な機能として、メッセージを初期化できる、ということがある。 ---この機能を使うと、ラウンドトリップのレイテンシがすげー縮まる。なぜならアプリケーションがスケジュールされるまで保留せず、代わりに即刻送信するからである。 --ASH はいろんな面白い機能を持っている（セクション 6 を見てね） -ダウンロードコードの顕著な話題としては、コードに指定される level がある。 -高レベルの言語は、より多くの semantic information を持つ。 -semantic information はより多くの最適化に関する情報を提供してくれる。 --例えばパケットフィルタ言語は、高レベルとして宣言されている。 --その結果パケットフィルタは、緊急の言語が実行不可能、状況下で低レベルをマージできる（文献 56）。（意味わかんね。） --しかし、そのような最適化が完了しなかった（割り込みハンドラの中とか）場合は、低レベル言語は、exokernel の philosophy に保持される（意味不明だ） --それはアプリケーションレベル言語のブロードキャストの範囲が、それを標的にできるようにして、単純な実装にする？？ -ASH はこのトレードオフの別の例である。ほとんどの ASH は基本となるマシンのオブジェクトコードの形式で、カーネルに取り込まれている。 --しかし少しの重要な場所（高レベルセマンティクスが有用なところ）では、機械語のインストラクションセットを拡張する。
