adv_system の履歴(No.1)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• adv_system へ行く。
  • 1 (2006-10-13 (金) 02:14:11)

---

sys_parallel

3. Exokernel のデザイン†

exokernelの挑戦†

• libOS が物理リソースを扱うという点において、最大限の自由を提供すること。その際に、他の者から守りつつ、自由を提供する。
  • 他の者から守るとは、プログラミングのエラーがある libOS が、他の libOS に影響を及ぼさないようにすること。

• この目標を達成すべく、exokernel は管理から、低レベルインタフェースまで、保護（protection）を分離させている。
  • なんだろ？？？

• 管理から保護を分離させるために、3つの重要なタスクがある
  1. リソースの所持者を追跡すること
  2. 全てのリソース使用や、バインディングポイント（binding points）をガードすることで、保護を保証すること
  3. リソースへのアクセスを破棄（revoking）すること

• これらのタスクを実現するために、exokernel は 3つの技術を使っている。
  1. secure bindings: libOS は物理リソースに対して、セキュアなバインド（securely bind）が可能である。
  2. visible rebocation: libOS が resource revocation protocol に参加できる。
  3. abort protocol: exokernel が使う。非協力的な libOS が行っているセキュアバインドを強制的にぶち壊せる。

このセクションでは exokernel アーキテクチャの設計原則を羅列している。そして先ほどの 3つの技術（管理と保護を分離するために使うもの）の詳細について議論している。

デザインの原則†

• exokernel は libOS のインタフェース（claim（要求？）, release（解放？）, 物理リソースの利用）について細かく指定している。

このセクションではいくつかの原則、つまり我々が libOS に最大限の操作性を与えるため exokernel のインタフェースをどうデザインしたか紹介する。

Security expose hardware†

• 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†

• exokernel では libOS が特定の物理リソースを要求しても良い。
  • 例えば、libOS は特定の物理ページ（メモリのかな？）を要求できるし、working set というので、ページ間でのキャッシュの衝突を減らすこともできる。（参考文献 29）
• さらに、リソースは暗黙のうちに割り当てられるべきではない。
  • libOS は各割り当ての決定に、関与（？ participate と書いてある）すべき。

次の原則ではこの関与（participation）の効用について補足している。

Expose Names†

• exokernel は物理名（physical names）を export すべき。
• 物理名は有能。
  • 理由は、仮想的な名前から物理的な名前に変換するために必要な、他のレベル（名前解決用、名前の変換レイヤってことか？）を除去できるから。
• 物理名はリソースの属性を便利に符号化できる。
  • 例えば、physically-indexed ダイレクトマップキャッシュを持つシステムだとして、物理ページ（例えば、ページ番号）から、どのページと衝突するかわかる。
• exokernel は book-keeping data（例えば、freelists、ディスクアームの位置、TLB のキャッシュしたエントリ）も export すべき。
  • アプリケーションが割り当て要求を調整できるように。

Expose Revocation†

• 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†

• exokernel はポリシーによる判定を libOS に手渡す。
  • リソースのこのコントロールを使うことで、アプリケーションまたは強調しあうアプリケーションの集合は、これらのリソースをどう使うのがベストなのか、決定を下すことができる。
• しかしどのシステムにおいても、exokernel は libOS 同士のかち合いを調停するために、ポリシーを include すべき。
  • exokernel は、異なるアプリケーションの絶対的な重要度（absolute importance）を決定しなければならない。リソースのシェアなどで。
  • この状況は、今までのカーネルと何も変わりない。
• OS のアーキテクチャによって決定するより、環境によって決定した方が適した機構である。
  • 例えば、リソースの管理を libOS に譲渡している間、exokernel はこれらリソースの割り当てや破棄を制御できる。

• 割り当て要求を与えることや、またどのアプリケーションから破棄するかを決めることで、exokernel は従来のストレージのパーティション（クオータ(quota)や、予約(reservation)スキーム）を強制できる。
• ポリシーの衝突は、結局はリソース割り当ての決定ということである。
  • シークタイム、物理メモリ、ディスクブロックの割り当てなど
  • exokernel は同じような方法でそれらを扱うだけ。

3.2 Secure Bindings†

• リソースをセキュアにを分割するのは、exokernel の基本的なタスクの一つ。
  • 保護を実装するためには、exokernel は libOS に secure binding を使ってもらう。

• secure binding とは、保護の機構である。
  • リソースの実際の利用から、分断された認証（decoupled authorization）である。
• secure binding は以下の 2点において、実行速度を改善する。
  1. 保護のチェックが secure binding を執行する（enforce）ことに含まれている。secure binding はいくつかの単純な命令で表せる。そのためカーネルあるいはハードウェアは、素早く実装できる。
  2. 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†

• プロトタイプでの 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†

• ネットワークの多重化は挑戦だ。
  • なぜならやってくるメッセージの中身に割り込んだり、受信者を特定するには、protocol-specific な知識が必要とされるから。

• ネットワークの多重化を解除する機能は、ソフトウェアあるいはハードウェアが提供できる。
  • ハードウェアベースだと、アプリケーションの securely bind streams として、ATM の仮想サーキットを使う方法（文献 19）がある。
  • ソフトウェアベースだと、