Exokernelとアプリケーション特化OSの原理

なぜ「抽象化しないOS」という発想が要るのか

従来の OS は、生のハードウェアを プロセス・仮想記憶・ファイル・ソケット といった固定の抽象へ畳み込み、すべてのアプリへ一様に提供します。これは移植性と安全性に優れる一方、抽象を選んだ時点で実装の自由が奪われる という代償を負います。たとえばファイルシステムのページキャッシュ置換が LRU 固定なら、データベースが持つ「次に読む順番の事前知識」を活かせません。アプリは自分にとって最適な資源管理を知っているのに、カーネルの中に固められた一般化された方針に従わされるのです。

MIT の Engler・Kaashoek らが提唱した Exokernel の出発点は、この一文に集約されます——カーネルは資源を保護せよ、ただし管理（抽象化・方針）はするな。資源を安全に多重化する最小限の機構だけをカーネルに残し、「どう抽象化するか」という方針をアプリ側へ完全に開放する。これが Exokernel の核心です。

保護と管理の分離：機構だけを残す

Exokernel の設計原理は 「機構（mechanism）はカーネル、方針（policy）はアプリ」 の極端な徹底です。カーネルが担うのは次の3つに限られます。

ここで配られる資源は 物理的に生（physical names） です。仮想ページ番号ではなく物理ページ番号、論理ブロックではなくディスクの物理ブロック番号がアプリへ渡されます。生の名前を晒すからこそ、アプリは アドレス変換 のページ表構造やディスク上のレイアウトを自分で設計でき、抽象化に伴う情報損失と間接層のコストを払わずに済みます。カーネルは「誰がその物理資源を所有しているか」だけを知り、所有権に基づいて触れてよいかを判定します。

secure binding：保護を多重化のたびに払わない仕組み

生資源をアプリへ晒しつつ保護を保つ鍵が secure binding（安全な束縛） です。原理はこうです——資源とアプリの結びつきを成立させる「authorization（権限検証）」と、その後の「multiplexing（多重利用）」を時間的に分離する。重い権限検証は束縛の生成時に一度だけ行い、以後の各アクセスは安価なチェックで通す、という考え方です。

具体例で言えば、ディスクブロックを所有するアプリは、そのブロック群の 自己記述メタデータ（どのブロックが誰のものかを示す情報）をカーネルへ提示します。カーネルはこれを検証して secure binding を張り、以後のブロック読み書きは所有権の照合だけで通します。ファイルシステムという抽象はカーネルにありません。inode の形式もディレクトリ構造も、すべてアプリ側の libOS が自分で決めるのです。

revocation：生資源を安全に取り上げる

資源を生で配ると、回収（取り上げ）が難題になります。仮想記憶なら、カーネルが裏でページを退避すればアプリは気づきません。しかし Exokernel は物理ページを直接渡しているため、勝手に奪うとアプリの自前ページ表が壊れます。そこで Exokernel は visible revocation（可視な回収） を採ります。

この設計は責任の所在を反転させます。従来 OS では「資源をいつ・どう奪うか」をカーネルが一手に決めましたが、Exokernel では 回収の方針すらアプリと分担 します。カーネルは「回収を始める」という機構だけを提供し、「何を犠牲にするか」はアプリが決めるのです。

ライブラリOS（libOS）：抽象はアプリのリンク先にある

カーネルが抽象を持たないなら、プロセスもファイルもソケットも誰かが実装せねばなりません。それを担うのが ライブラリOS（library operating system, libOS） です。libOS は従来カーネル内にあった抽象——仮想記憶管理、スケジューラ、ファイルシステム、ネットワークスタック——を アプリにリンクされる通常のライブラリ として実装します。

これがもたらす最大の利得は アプリごとの特化 です。データベースは独自のバッファ置換とログ先行書き込みを持つ libOS を、Web サーバーはゼロコピー I/O に振り切った libOS を、それぞれ選んでリンクできます。libOS の改変に カーネルモード への移行も再起動も要りません。普通のライブラリを差し替えるだけだからです。MIT の研究実装 Aegis/ExOS では、ExOS が libOS として UNIX 互換のプロセス・パイプ・シグナルを再現し、それでいて IPC やページフォルト処理を従来カーネルより大幅に高速化できることが示されました。

ただし代償もあります。libOS 間で資源を 共有 する抽象——共有ファイルへの一貫したアクセスや、互いに信頼しないアプリ間の協調——は、カーネルに共通の抽象がないぶん、libOS 側のプロトコル設計が難しくなります。万人向けの妥協を捨てた自由は、相互運用の負担と引き換えなのです。

マイクロカーネルとの思想的差異

Exokernel はしばしば マイクロカーネル と混同されますが、両者の狙いは根本から異なります。マイクロカーネルは抽象を カーネル外のサーバープロセスへ移設 するもので、ファイルシステムや ドライバ をユーザー空間のサーバーとして動かし、IPC で呼び出します。抽象自体は残り、置き場所が変わる のです。

決定的な差は 間接層の有無 です。マイクロカーネルではアプリと資源の間にサーバープロセスが挟まり、IPC の往復コストと、サーバーが固定した抽象という制約が残ります。Exokernel は libOS をアプリと同一アドレス空間に置くため、抽象へのアクセスは IPC ではなく 関数呼び出し です。そして抽象の設計権がアプリにあるため、サーバーが押しつける方針も存在しません。マイクロカーネルが「抽象の置き場所を変える」改革なら、Exokernel は「抽象の決定権を移す」改革だと言えます。

まとめ