マイクロカーネルとは? わかりやすく解説

Weblio 辞書 > 辞書・百科事典 > デジタル大辞泉 > マイクロカーネルの意味・解説 

マイクロカーネル【microkernel】

読み方:まいくろかーねる

オペレーティングシステム中核部であるカーネルに、特に汎用性の高い基本機能だけをもたせて小型化したもの


マイクロカーネル

【英】microkernel

マイクロカーネルとは、OS中核部分であるソフトウェア群(カーネル)に必要最小限機能だけを搭載することで、小型化と処理の高速化を図る手法のことである。あるいは、そのように設計されカーネルのこともマイクロカーネルと呼ぶ。

通常のカーネルには備わっている機能は、独立した外部モジュールとして切り離されている。マイクロカーネル自体は、メモリー管理割り込み要求プロセス交信など、汎用性の高い機能だけを備える。この構造カーネル内部の処理の並列化実現し、処理能率向上している。同時に小型化実現される

マイクロカーネルの概念取り入れた製品としては、カーネギーメロン大学開発したMachマークオペレーティングシステムなどが代表的である。Windows NTWindows 2000内部にもマイクロ カーネルの技術取り入れられており、HALHardware Abstraction Layer)と呼ばれるハードウェア依存部分独立した形をとっている。

マイクロカーネルでは、外部機能モジュールプログラム部品)として外部用意されるカーネル出された処理要求多くは、カーネル内部から外部モジュール呼び出して行われることになる。モジュール化されることで、機能整理しやすくなり、追加移植容易になるメリットがある。ただし、純粋なマイクロカーネルの構造にしてしまうと、サブシステム間での通信や、サブシステムコアOSとの間でのスイッチにかかるオーバーヘッド大きくなり、実用的でなくなる。そのためWindows 2000では、HALと各サブシステムとの間にExecutiveエグゼクティブ)と呼ばれる中間層設け、ここにネットワークグラフィックス機能組み込むことで、オーバーヘッド低減させるようにしている。

マイクロカーナルに対して従来カーネルにおける(カーネル様々な機能実装していく)手法がは、モノリシックカーネル呼ばれるモノリシックカーネル採用している代表的なOSとしてはLinuxがある。

ソフトウェアのほかの用語一覧
OS:  LiveUSB  Mac OS  MS-DOS  マイクロカーネル  マルチタスク  内部コマンド  ノンプリエンプティブマルチタスク

マイクロカーネル

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2023/10/12 01:55 UTC 版)

モノリシックカーネル及びマイクロカーネルのOSの構成
マイクロカーネルの概念図

マイクロカーネル: microkernel)とはオペレーティングシステム (OS) の設計思想、及びそのようなOSのカーネル部の名称である。OSが担う各種機能のうち、必要最小限のみをカーネル空間に残し、残りをユーザーレベルに移すことで全体の設計が簡素化でき、結果的にカスタマイズ性が向上し、性能も向上できるというOSの設計手法のことである。カーネル本体が小規模な機能に限定されるので「マイクロカーネル」と呼ばれるが、必ずしも小さなOSを構成するとは限らない。

マイクロカーネルの出現に伴い、従来型のOSを「モノリシックカーネル(一枚岩のカーネルという意)」と呼ぶようになった。マイクロカーネルの思想を更に推し進めたナノカーネルも提唱されている。

特徴

純粋なマイクロカーネルでは、まずカーネル空間で提供される機能を、メモリ空間の仮想化プロセス制御プロセス間通信に限定し、割り込みなども全て通信にマップする。その上でファイルシステムデバイスドライバといった準カーネル機能をそれらのアプリケーションとして実装し、ユーザー空間で動作させる。場合によってはそれらの機能セットをサーバと呼ばれる単位で複数動作させる。

このような形態を持つ事のメリットは、

  • OS開発効率の向上(機能拡張、デバッグなどを容易に行える)
  • システム全体を止めずにカーネル以外のOSのアップデートを行うことができる
  • 必要な機能のみを提供するアプリケーションに特化したOSを構築することが容易になる

などである。また一般にマイクロカーネルでは資源の抽象度が高く、マルチプロセッサ対応やネットワーク透過の通信が自然に実装できるため、大規模な資源利用には有利である。

反面あらゆる場所でプロセス間通信を利用する為、機能相互のオーバーヘッドが大きく、モノリシックカーネルと同等の機能を実装した場合、数パーセントから数倍のロスが出る場合がある。特にコンテキストスイッチのコストを避けるため、必要な機能をカーネル空間に移し、見た目上モノリシックカーネルのように動作させる場合もある(co-location)。

歴史

初期のOSのカーネルは、コンピュータのメモリ容量が小さかったこともあって、比較的小さかった。コンピュータの能力が成長するに従い、カーネルが制御しなければならないデバイスの数も増えていった。それでも例えば当初のUNIXのカーネルは、デバイスドライバやファイルシステムを含んでいても一般に小さかった。アドレス空間が16ビットから32ビットに拡大すると、カーネル設計がハードウェアアーキテクチャに束縛されることがなくなり、カーネルの成長が始まった。

UNIXカーネルの肥大化の端緒となったのが Berkeley Software Distribution (BSD) である。それまでのOSの役割に加え、BSDでは複数のファイルシステムを追加し、完全なTCP/IPプロトコルスタックを備え、ネットワーク上で既存のプログラムを動作可能にする各種仮想デバイスが追加されている。UNIXはファイルという概念でリソースを統一し、ファイルを扱う小さなプロセスをパイプでつないで相互通信させることにより、コンパクトかつ高機能なOS設計に成功した。しかしその後の利用環境の変化に伴い、必ずしもファイルとして扱えないリソースが増加している。例えばネットワーク通信はソケットという概念で行われるが、ソケットはファイルではない。結果的に、後付けで似て非なるコードがOSを肥大化させるという事態が発生したといえる。このような成長が何年も続き、カーネルのソースコードは数百万行にまで肥大化した。結果として、バグが潜在している可能性が高まり、保守の困難さが増していった。

マイクロカーネルはそのような「UNIXの再設計」という観点から始まっている。理論上、マイクロカーネル設計はカーネルの一部だったサービス群をユーザー空間に切り出すことでコードの管理を容易にするとされていた。また、カーネルモードで動作するコードの量を減らすことで、セキュリティと安定性が増すと考えられた。例えば、ネットワークサービスがバッファオーバーランでクラッシュしても、マイクロカーネルは影響を受けないので、システム全体としては機能し続けることができる。

OSがたくさんのコードから成る事の直接的な問題点は、

  • カーネル自体が占めるメモリ領域(カーネル空間のフットプリント)が大きくなる
  • 移植性やメンテナンスに不利

といったものである。さらに、計算機資源の増大に伴いマルチプロセッサや仮想メモリといった、UNIX開発時に想定していなかった実装が出現しており、それらを含めたOS概念のリファインが必要と考えられた。

そこで、「大規模な資源」と「高速な通信」を念頭において「相互通信するプロセスによる協調動作」というUNIXの発展理念に至ったのがマイクロカーネルである。UNIXではファイルを中心概念としていたが、マイクロカーネルではプロセスと通信に主眼を移し、割り込みやI/Oといったあらゆる資源が徹底的に抽象化されている。

そのような背景で1980年代に開発されたマイクロカーネルは、既存の一体型カーネルを新たなシステムへ適応させるいくつかの試みを伴っていた。従来型カーネルに含まれていたデバイスドライバ、プロトコルスタック、ファイルシステムや他の低レベルシステムを一度に新たに開発するため、膨大な作業を伴い、慎重なコード管理が必要とされた。ユーザー空間のプログラムとして実装されたサービスは通常のユーザープログラムのように動作する。そのためそれらサービスの扱いが容易になっただけでなく、残ったカーネル部分は副作用を気にせずに最適化することができる。さらに言えば、共通の中核部の上に全く新たなOSを構築することも可能になり、OS研究にも寄与した。

なお、この時古くなった計算機資源の再利用も考慮されていた。つまり、移植性が高くコンパクトなOSを使えば、旧式のシステムであってもネットワーク上に接続して資源として活用する事ができるという考え方である。

1980年代には初期の Local Area Network が登場しており、マイクロカーネルは非常に有望な技術とされていた。カーネルの機能をユーザー空間に分散させる機構を使えば、システムをネットワーク上に分散させることも可能だからである。Machなどの初期のマイクロカーネルは、性能に問題があることが判明したが、それよりも利点が大きいとみなされ、1990年代末までOS研究の中心となった。実際に実装されたMachでは、当初の予想通りコード量の削減には成功した。抽象度が高く、見通しの良いマイクロカーネルはトレンドとしては妥当であり、この時は将来有望な物と見なされている。しかし、その間にコンピュータの性能がネットワーク性能に比べて格段に向上し、マイクロカーネルの性能問題は開発の容易さという利点を考慮しても無視できなくなった。既存システムを性能向上させる様々な試みがなされたが、オーバーヘッドが常に問題となり、性能向上のためにはユーザー空間のプログラムとなったサーバをカーネルに戻す必要があった。2000年までにMachのような大規模な試みはなされなくなったが、OPENSTEPが採用したXNUというMachカーネル改良版は DarwinmacOS で採用されている[1]。2012年現在、Machベースの GNU Hurd も機能しており、それを採用した Arch LinuxDebian のテスト版も進行中である。

マイクロカーネルの大規模な研究は下火になったが、研究開発は続けられた。初期のマイクロカーネル設計における性能問題の多くは方針の根本的の問題ではなく、たまたまある目的のために実装されたシステムを可能な限り多くのサービスに使おうとする設計者の願望に起因していたと見られるようになった。アセンブリコードを使ったり、通常はソフトウェアでサポートすることをプロセッサのアーキテクチャ独自の機能に頼るなどのより実用的なアプローチを通して、性能が劇的に改善されたマイクロカーネルが登場するようになった。このような新世代のマイクロカーネルを従来の多くのシステムサービスを含んだ実装と区別するため、ナノカーネル (nanokernel) という呼称も使われた。しかし、従来型のマイクロカーネルからナノカーネルへの移行がほぼ完了すると、ナノカーネルとは呼ばれなくなっている。

マイクロカーネルと密接に関連する方式としてエクソカーネルがある[2]。エクソカーネルはハイパーバイザと共通点が多いが[3]、極小性を主張することはなく、仮想機械サポートに特化している。実際、L4マイクロカーネルファミリーはハイパーバイザの実装によく使われている。

マイクロカーネル自体ではなく、それに付随して開発された機能やマイクロカーネルの設計思想がマイクロカーネル以外のOSへ影響を及ぼした事例がある。インタフェースの明確な定義がもたらした高い移植性や、カーネルへの依存性を軽減したOS機能の実装がきっかけとなっている。Machの仮想記憶サーバは4.4BSDのカーネルへ移植され、その子孫を含めて旧来の仮想記憶実装を置き換えた。ユーザプロセスとしてファイルシステムのドライバを実装したFUSEは実装の容易さや障害への強さなどマイクロカーネルの技術的なメリットだけでなく、Linux上での初期のZFSサポートのように技術以外の問題(この場合はライセンスの非互換性)を回避する手段ともなっている。

プロセス間通信

プロセス間通信 (IPC) とは、プロセス間の通信を可能にする何らかの機構であり、メッセージ送信がよく使われる。共有メモリも厳密にはプロセス間通信機構の一種だが、マイクロカーネルでIPCといえば一般にメッセージを指す。IPCにより、OSをサーバといういくつかの小さなプログラムで構築することができ、IPCを使ってサーバを他から呼び出すことができる。周辺ハードウェアのサポートもそのように実装でき、サーバにはデバイスドライバ、ネットワークのプロトコルスタック、ファイルシステム、グラフィックスなど様々なものがある。

IPCには同期式と非同期式がある。非同期IPCはネットワーク通信に似ている。送信側はメッセージを発行して処理を継続する。受信側はメッセージの到着を定期的にチェックするか、何らかの検出機構で通知される。非同期IPCではカーネルがメッセージ用のバッファとキューを管理しており、バッファオーバーフローもカーネルが扱う。また、メッセージは2回コピーされる(送信側からカーネル、およびカーネルから受信側)。同期IPCでは、送信側か受信側はもう一方がIPC可能となるまでブロックされる。バッファリングも複数回のコピーも不要だが、明示的に両者が待ち合わせる必要があるため、プログラミングに巧妙さを必要とする。多くのプログラマは非同期送信と同期受信を好む。

第一世代のマイクロカーネルは一般に同期IPCも非同期IPCもサポートしていたが、その性能は悪かった。ヨッヘン・リートケ はその原因がIPC機構の設計と実装にあることを示した。彼はL4マイクロカーネルでIPCコストを10分の1以下にした[4]。IPCは送信も受信もシステムコールでサポートされ、同期式のみであり、レジスタでなるべく多くのデータを渡すようにしている。さらにリートケは direct process switch という概念を導入し、IPCの際に送信側から受信側へ直接(不完全な)コンテキストスイッチを行うようにした。そのためL4では、メッセージの一部または全部をレジスタ群で渡す場合、レジスタ内のメッセージは全くコピーせずに転送することができる。さらにスケジューラを呼び出すオーバーヘッドを排除している。これは特に遠隔手続き呼出し (RPC) 的にサーバを呼び出す際のIPCに適している。もう1つの最適化として lazy scheduling と呼ばれるものがあり、IPC中にスケジューリングキューを走査せずに済むようするため、IPC中はスレッドをレディキューでブロックしたままにする。スケジューラが呼び出されると、そのようなスレッドを適当な待ちキューに移す。

クライアント・サーバ型システムでは多くの通信が基本的に同期式であり、非同期なプリミティブを使っていたとしても、通常はクライアントがサーバを呼び出し、応答を待つことになる。その方が実装も効率的になるため、L4以降のマイクロカーネルでは同期IPCプリミティブのみを提供するようになった。非同期IPCは補助スレッドを使って同期IPCプリミティブ上で実装できる。しかし、L4を採用した商用製品では非同期通信サポートのために非同期通知機構が必要であることが判明し、それを追加している。このシグナルのような機構はデータを転送するものではなく、カーネルによるバッファリングが不要である。

同期IPCでは通信の一方が応答可能になるまでもう一方がブロックされる。したがって無制限にIPCを使用すると容易にデッドロック状態が発生する。また、クライアントが要求を送って応答を待ち合わせないようにすると、容易にDoS攻撃のような状態になる。したがって同期IPCでは長期に渡るブロックを防ぐ手段を提供しなければならない。多くのマイクロカーネルはIPC呼び出しにタイムアウトを提供しており、ブロック時間を制限している。実際にはタイムアウト時間の設定は難しく、結果としてクライアントのタイムアウトは無制限、サーバのタイムアウトはゼロとすることが多い。結果としてタイムアウト時間を任意に設定できるようにせず、相手が応答可能でない場合にIPCを即座に失敗させるかどうかを示すフラグだけを用意する傾向になってきた。それによってタイムアウト時間としてゼロか無制限かを選択することになる。L4やMINIXの最近のバージョンもそのようになっている(QNXや以前のL4ではタイムアウト時間を任意に設定できる)。

サーバ

マイクロカーネルでのサーバはデーモンのようなものだが、一部のサーバは物理メモリ空間の一部にアクセスできる特権を与えられている。それによりデバイスドライバのサーバがハードウェアと直接やりとりできるようになっている。

汎用マイクロカーネルにおける基本的サーバとしては、ファイルシステムサーバ、デバイスドライバサーバ、ネットワークサーバ、ディスプレイサーバ、ユーザインタフェースデバイスのサーバなどがある。これらのサーバ群でUnix系モノリシックカーネルの提供するサービスをほぼカバーしている。必須サーバは立ち上げ時に起動してサービスを開始する。サーバはユーザーアプリケーションと同様の環境で動作し、その開発もアプリケーションと似ている。カーネル開発で必要となる頻繁なビルドリブートは不要である。

さらに、サーバで障害が発生してもシステム全体がクラッシュすることはなく、単にそのサーバを再起動すればよい。しかし、サーバで障害が発生することでシステム状態の一部が失われることがあるため、アプリケーション側もサーバ障害に対応する必要がある。例えば、TCP/IP接続を担うサーバがあるとする。このサーバを再起動すると、アプリケーションから見てコネクションが失われることになるが、これは通常のネットワークでも起き得る障害である。しかしアプリケーションが障害発生を予期していないサービスの場合、アプリケーションのコードを修正する必要がある。QNXではサーバの再起動への対応として QNX High Availability Toolkit が提供されている[5]

全サーバを再起動可能にするため、トランザクションレプリケーションチェックポインティング英語版といったデータベース的技法を取り入れているマイクロカーネルもある。例えば ChorusOS があり、電気通信業界の高信頼アプリケーション用にそのような機能を備えている。

デバイスドライバ

Direct Memory Access (DMA) を頻繁に行うデバイスドライバは、カーネルのデータ構造を含めた物理メモリの任意の位置に書き込める必要がある。そのようなドライバは信頼されていなければならないが、必ずしもカーネル内に含まれている必要はない。実際、カーネルの一部だからといってデバイスドライバがより信頼できるというわけではない。

デバイスドライバをユーザー空間で動作させたとしても、ドライバが発生しうる障害のダメージが低減されることはないが、バグのあるドライバによってシステムの安定性が影響を受けにくくするという効果はある(悪意あるドライバの場合はその限りではない)。(デバイスではなく)ドライバのコード自体が不正なメモリアクセスを行う場合、メモリ管理ハードウェアが捉えることになる。さらにDMAを行わないデバイスでは、ユーザー空間で動作させることでドライバを信頼されないもの(特権が不要なもの)とすることができる。最近ではIOMMUを備えたコンピュータが増えており、IOMMUを使ってデバイスの物理メモリアクセスを制限できることが多い[6]。これもユーザーモードのドライバを信頼されないものとすることができる。

ユーザーモードのドライバは実際にはマイクロカーネルより古くから存在する。1967年の Michigan Terminal System (MTS) で初めて(ファイルシステムも含めた)ユーザー空間のドライバがサポートされた[7]。歴史的には、ドライバをカーネルに含めることはあまり問題とされなかった。周辺デバイスの数は少なく、特権が必須だったためであり、カーネルに含めることで性能問題を防いでいた。Unixもそのスタイルを踏襲し[8]、Linuxや Windows XP 以前のWindowsも同様だった。デバイスの種類が豊富になってくると、ドライバのコード量も増大するようになり、カーネル全体に占める割合も増えていった。

必須コンポーネントと極小性

マイクロカーネル上で任意のOSサービス群を構築しなければならない場合、マイクロカーネルはいくつかの中核機能を提供しなければならない。最小でも以下が含まれる。

このような最小設計は Per Brinch HansenNucleus とIBMのVM英語版のハイパーバイザがさきがけである。そして、リートケの「極小原則」として次のように定式化された。

ある概念をマイクロカーネル内で実現することが許されるのは、それをカーネルの外に移した場合、すなわち競合する実装が可能となることでシステム必須の機能が妨げられる場合だけである。[9]

他のあらゆるものはユーザーモードのプログラムとして実装できるが、デバイスドライバをユーザープログラムとして実装する場合、一部のプロセッサアーキテクチャではI/Oハードウェアにアクセスするための特別な特権を必要とする。

極小原則とも関連しマイクロカーネル設計で重要な観点として機構と方針の分離があり、極小のカーネル上に任意のシステムを構築できるようにするのに必要である。方針をカーネル内で実装すると、ユーザーレベルでは上書きできず、マイクロカーネルの可能性が一般に制限される[2]。ユーザーレベルのサーバで実装された方針はサーバを置換することで(あるいは同様のサービスを提供する複数のサーバからアプリケーションが選択することで)変更できる。

効率化のため、ほとんどのマイクロカーネルはスケジューラとタイマー管理を含んでおり、極小原理と機構と方針の分離の原則に反している。

マイクロカーネルを使ったシステムの立ち上げ(ブート)では、カーネル内に含まれないデバイスドライバが必要になる。一般に必要なデバイスドライバをカーネルと共にパッケージ化してブートイメージを作成する必要があり、カーネルはデバイスドライバを配置して起動する手順をサポートしている必要がある。例えばL4ではそのようなブート方式になっている。一部のマイクロカーネルは重要なデバイスドライバを(極小原則に反して)カーネルに含めており、LynxOSや元々のMINIXが挙げられる。ブートを単純化するため、ファイルシステムまでもカーネルに含める場合がある。マルチブート対応のブートローダからブートできるマイクロカーネルのシステムもある。その場合、静的リンクされたサーバ群をロードするか、OSイメージをマウントすることで立ち上げを続行する。

マイクロカーネルにおいては、IPCシステムと仮想記憶管理の設計が重要であり、ページフォールト処理やスワッピングをユーザーモードのサーバで安全に実装できるようにすることが肝要である。全サービスがユーザーモードのプログラムで実行されるので、それらプログラム間の効率的通信手段が必須である。これはモノリシックカーネルに比べて遥かに重要である。効率化するには、IPCシステムのオーバーヘッドを小さくするだけでなく、CPUスケジューリングともうまくやりとりしなければならない。

性能

多くの主流のプロセッサにおいて、サービスを得るのにかかるコストはモノリシックカーネルよりもマイクロカーネルの方が本質的に高い[2]。モノリシックなシステムでは、サービスを得るのに1回のシステムコールを使用し、その際に2回の「モード切り換え」(プロセッサのリングまたはCPUモードの変更)を必要とする。マイクロカーネルを採用したシステムでは、サービスを得るにはサーバにIPCメッセージを送り、別のIPCメッセージで結果を得る必要がある。このときドライバがプロセスとして実装されていればコンテキストスイッチが必要であり、プロシージャとして実装されていれば関数呼び出しが必要である。さらに実際にデータをサーバに渡して結果のデータを戻してもらうには、データをコピーするオーバヘッドが余分にかかる。モノリシックカーネルでは、クライアント(ユーザー空間)の持つバッファにあるデータに直接アクセス可能である。

したがってマイクロカーネルシステムには性能問題が潜在している。実際、MachChorusOSといった第一世代のマイクロカーネルを採用したシステムの性能は低かった[10]。しかしヨッヘン・リートケはMachの性能問題は設計と実装がまずかったためであることを示し、特にMachがページキャッシュ英語版を使いすぎていることを指摘した[9]。リートケは自身のL4マイクロカーネルを注意深く設計・実装することで、特に極小原則に従えばIPCコストをMachの10分の1以下にできることを証明した。L4のIPC性能は様々なアーキテクチャ上で最速を誇った[11][12][13]

そういった結果により、第一世代のマイクロカーネルの性能の低さは第二世代のL4などのマイクロカーネルには当てはまらないことを示したが、マイクロカーネルをベースにしたシステムが高性能を発揮できることを証明したわけではなかった。それでもモノリシックなLinuxサーバをL4上に移植したものは、通常のLinuxに対して数パーセントのオーバーヘッドを示しただけだった[14]。しかし、単一サーバシステムはマイクロカーネルの利点を生かしているとは言い難く、OSの機能を複数のサーバに分離したときの性能が重要だとされた。

複数サーバの商用システムはいくつか存在しており、例えばリアルタイムオペレーティングシステムQNXIntegrity英語版がある。そういったシステムとモノリシックなシステムとの包括的性能比較は公表されたことがない。さらに言えばそれら商用システムでは性能が最重要課題ではないようで、割り込み応答時間の保証や頑健性のための単純さが強調されている。複数サーバの高性能OSを構築する試みとしてIBMの Sawmill Linux というプロジェクトがあった[15]。しかし、このプロジェクトは完了することなく中止された。

同じころ、ギガビット・イーサネットのような高速デバイスのデバイスドライバをユーザーレベルで実装したものが、カーネル内のデバイスドライバと同等の性能を発揮することが示されている[16]。これは複数サーバの高性能システムが構築可能であることを示唆している。

セキュリティ

マイクロカーネルはセキュリティ面で優れているとよく言われてきた[17][18]。セキュリティの観点では、マイクロカーネルの極小原則は、全てのコードについて必要とされる機能を提供するのに必要な権限だけを持つべきであるという最小権限の原則の直接的帰結である。極小性は、システムのトラステッド・コンピューティング・ベース英語版 (TCB) を極小に保つべきであることを要求する。カーネル(ハードウェアの特権モードで実行されるコード)は常にTCBの一部であり、セキュリティ指向設計ではそれを極小化するのが自然である。

結果として、マイクロカーネル設計は高度なセキュリティを要求される用途で採用されており、例えばKeyKOS英語版EROS英語版、軍用システムなどがある。実際、コモンクライテリア (CC) の最高保証レベル(評価保証レベル (EAL) 7)では、対象の評価が「単純」であること、複雑なシステムの真の信頼性を確立するのに実際的不可能性を確認できることを明示的に要求している。

第三世代

近年のマイクロカーネル研究開発は、カーネルAPIの形式仕様とそのAPIのセキュリティ属性の形式的証明に集中している。第一の例として、EROSでの隔離機構の数学的証明があり、EROS API を単純化したモデルに基づいている[19]。より最近の例として、L4のバージョンの一種である seL4 のプロテクションモデルについて自動検証された包括的な証明がなされている[20]

それにより「第三世代マイクロカーネル」と呼ばれるものが生まれている[21]。これはセキュリティ指向のAPI、ケイパビリティによるリソースアクセス制御、最重要概念としての仮想化、カーネル資源管理への革新的アプローチ[22]形式的分析に適した設計、などを特徴としつつ、性能向上を目標としたものである。例として、Coyotos英語版、seL4、Nova[23][24]、Fiasco.OC[23][25]などがある。

seL4の場合、実装についての完全な形式的検証がなされており[21]、形式仕様と実装が一致していることが数学的に証明されている。それにより、APIについて証明された属性が実際のカーネルでも保持されていることが保証でき、CC EAL7 をも越える保証の程度となっている。

ナノカーネル

ナノカーネル (nanokernel) またはピコカーネル (picokernel) という用語は歴史的には次のような意味で使われてきた。

  1. カーネルコードの量、すなわちハードウェアの特権モードで実行されるコードの量が極めて小さいカーネル。カーネルが極めて小さいことを強調する際に「ピコカーネル」という呼称も使われた。「ナノカーネル」という用語を生み出したのは Jonathan S. Shapiro で、The KeyKOS NanoKernel Architecture (1992) という論文で初めて使っている。それはMachへの冷笑的反応であった。彼はMachについて、本質的に非構造的であり、モノリシックであるのにマイクロカーネルと主張しているだけで、置き換えようとしているものより性能が悪いと評した。その用語が他でも使われ、さらにピコカーネルという呼称が生まれた背景には、従来のマイクロカーネルが「カーネルが小さい」という点から大きく外れていったことを示唆している。その後、ナノカーネルとピコカーネルはマイクロカーネルと同じ意味で使われるようになった。
  2. OSの下にある仮想化層。より正確には「ハイパーバイザ」と呼ばれる。
  3. カーネルの最下層部を形成している ハードウェア抽象化層。例えば Adeos があり、通常のOSにリアルタイム機能を提供するのに使われる。

また、小さくないカーネルをナノカーネルと呼ぶ用例も少なくとも1つあり、その場合はクロック間隔としてナノ秒単位までサポートしているカーネルを指す[26]

脚注

  1. ^ Porting UNIX/Linux Applications to Mac OS X”. Apple. 2011年4月26日閲覧。
  2. ^ a b c Liedtke, Jochen (September 1996). “Towards Real Microkernels”. Communications of the ACM 39 (9): 70–77. doi:10.1145/234215.234473. 
  3. ^ Heiser, Gernot; Uhlig, Volkmar and LeVasseur, Joshua (January 2006). “Are Virtual-Machine Monitors Microkernels Done Right?”. ACM SIGOPS Operating Systems Review (ACM) 40 (1): 95–99. doi:10.1145/1113361.1113363. 
  4. ^ Liedtke, Jochen (December 1993). "Improving IPC by kernel design". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 175–88.
  5. ^ QNX High Availability Toolkit
  6. ^ Wong, William (2007-04-27). “I/O, I/O, It's Off to Virtual Work We Go”. Electronic Design. http://electronicdesign.com/article/embedded/i-o-i-o-it-s-off-to-virtual-work-we-go15350 2009年6月8日閲覧。. 
  7. ^ Alexander, Michael T. (1971). “Organization and Features of the Michigan Terminal System”. Proceedings of the November 16–18, 1971, fall joint computer conference 40: 589–591. doi:10.1145/1478873.1478951. 
  8. ^ Lions, John (1977-08-01). Lions' Commentary on UNIX 6th Edition, with Source Code. Peer-To-Peer Communications. ISBN 978-1-57398-013-5 
  9. ^ a b Liedtke, Jochen (December 1995). "On µ-Kernel Construction". 15th ACM symposium on Operating Systems Principles. pp. 237–250. doi:10.1145/224056.224075
  10. ^ Chen, Bradley; Bershad, Brian (December 1993). "The Impact of Operating System Structure on Memory System Performance". 14th ACM Symposium on Operating System Principles. Asheville, NC, USA. pp. 120–33. doi:10.1145/168619.168629
  11. ^ Liedtke, Jochen; Elphinstone, Kevin; Schönberg, Sebastian; Härtig, Hermann; Heiser, Gernot; Islam, Nayeem; Jaeger, Trent (May 1997). "Achieved IPC performance (still the foundation for extensibility)". 6th Workshop on Hot Topics in Operating Systems. Cape Cod, MA, USA: IEEE. pp. 28–31.
  12. ^ Gray, Charles; Chapman, Matthew; Chubb, Peter; Mosberger-Tang, David; Heiser, Gernot (April 2005). "Itanium—a system implementor's tale". USENIX Annual Technical Conference. Annaheim, CA, USA. pp. 264–278.
  13. ^ van Schaik, Carl; Heiser, Gernot (January 2007). "High-performance microkernels and virtualisation on ARM and segmented architectures" (PDF). 1st International Workshop on Microkernels for Embedded Systems. Sydney, Australia: NICTA. pp. 11–21. 2007年4月1日閲覧
  14. ^ Härtig, Hermann; Hohmuth, Michael; Liedtke, Jochen; Schönberg, Sebastian (October 1997). “The performance of µ-kernel-based systems”. Proceedings of the sixteenth ACM symposium on Operating systems principles: 66–77. doi:10.1145/268998.266660. ISBN 0-89791-916-5. http://portal.acm.org/citation.cfm?id=266660&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618. 
  15. ^ Gefflaut, Alain; Jaeger, Trent; Park, Yoonho; Liedtke, Jochen; Elphinstone, Kevin J.; Uhlig, Volkmar; Tidswell, Jonathon E.; Deller, Luke; Reuther, Lars (2000). "The Sawmill multiserver approach". 9th ACM SIGOPS European Worshop. Kolding, Denmark. pp. 109–114.
  16. ^ Leslie, Ben; Chubb, Peter; FitzRoy-Dale, Nicholas; Götz, Stefan; Gray, Charles; Macpherson, Luke; Potts, Daniel; Shen, Yueting; Elphinstone, Kevin; Heiser, Gernot (September 2005). “User-level device drivers: achieved performance”. Journal of Computer Science and Technology 20 (5): 654–664. doi:10.1007/s11390-005-0654-4. 
  17. ^ Tanenbaum, Andrew S., Tanenbaum-Torvalds debate, part II
  18. ^ Tanenbaum, A., Herder, J. and Bos, H. (May 2006).
  19. ^ Shapiro, Jonathan S.; Weber, Samuel. "Verifying the EROS Confinement Mechanism". IEEE Conference on Security and Privacy. 2016年3月3日時点のオリジナルよりアーカイブ。
  20. ^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). Verified Protection Model of the seL4 Microkernel. submitted for publication. http://www.nicta.com.au/pub?doc=1474 
  21. ^ a b Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (October 2009). "seL4: Formal verification of an OS kernel" (PDF). 22nd ACM Symposium on Operating System Principles. Big Sky, MT, USA.
  22. ^ Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). "Kernel design for isolation and assurance of physical memory". 1st Workshop on Isolation and Integration in Embedded Systems. Glasgow, UK. doi:10.1145/1435458
  23. ^ a b TUD Home: Operating Systems: Research: Microkernel & Hypervisor”. Faculty of Computer Science. Technische Universität Dresden (2010年8月12日). 2011年11月5日閲覧。
  24. ^ Steinberg, Udo; Kauer, Bernhard (April 2010). "NOVA: A Microhypervisor-Based Secure Virtualization Architecture". Eurosys 2010. Paris, France. pp. 209–222.
  25. ^ Lackorzynski, Adam; Warg, Alexander (March 2009). "Taming Subsystems - Capabilities as Universal Resource Access Control in L4". IIES'09: Second Workshop on Isolation and Integration in Embedded Systems. Nuremberg, Germany.
  26. ^ http://www.eecis.udel.edu/~mills/database/papers/nano/nano2.pdf

参考文献


マイクロカーネル

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/09/16 14:38 UTC 版)

カーネル」の記事における「マイクロカーネル」の解説

詳細は「マイクロカーネル」を参照 マイクロカーネルとは、伝統的なカーネル」から「サーバ」群に機能移転するOS設計方針意味し最小化したカーネルだけをカーネル空間残しサーバ群を可能な限りユーザ空間動作させる。マイクロカーネルでは、ハードウェア単純な抽象化最小プリミティブシステムコール)で最小OSサービス実装する(メモリ管理マルチタスクプロセス間通信など)。他の全てのサービスネットワークなど)は「サーバ」としてユーザ空間実装される。マイクロカーネルはモノリシックカーネルよりも保守容易だが、システムコール回数コンテキストスイッチ回数増大するために性能低下する傾向がある。 どうしても特権モードなければならない部分だけがカーネル空間置かれる。それは、IPCプロセス間通信)、基本スケジューラ(スケジューリング・プリミティブ)、基本メモリハンドラ、基本I/Oプリミティブなどである。スケジューラ本体メモリ管理ファイルシステム、ネットワークスタックといった大部分ユーザ空間動作する。マイクロカーネルは、システム機能全体プロセッサのシステムモードで動作する1つプログラムになっているモノリシックカーネル設計方針への反発から生まれた。マイクロカーネルを採用したOSとしては、QNXGNU Hurd がある。マイクロカーネルは基本的に次のような長所を持つ。 保守相対的に容易である。 パッチ評価が容易である。 すばやく開発でき、多く場合カーネル再起動しなくとも評価可能。 サーバ障害発生しても、運用上のミラー代行可能なことが多くバグへの耐性が高い。 多くのマイクロカーネルは、何らかのメッセージパッシングシステムを採用しており、サーバからサーバへの要求転送を行う。一般にマイクロカーネルがそのためのポート用意している。例えメモリ追加要求を送ると、マイクロカーネルのあるポート開き、そこを通して要求転送される。マイクロカーネルにメッセージ受信されると、その後システムコールのように処理される。これによってシステムアーキテクチャモジュール性高まりシステムがより整理されデバッグ動的変更容易になり、ユーザーニーズ従ったカスタマイズが可能となる。AIXBeOSHurdmacOSMINIXQNX といったOS多かれ少なかれマイクロカーネルの設計方針取り入れている。マイクロカーネル自体は非常に小さいが、システム機能全体構成するコード全て集めると、モノリシックカーネルよりも大きいことが多い。モノリシックカーネル支持派また、マイクロカーネル方式2層構造によりOS大部分ハードウェア直接相互作用できなくなるため、決し小さくないコスト上乗せされ、システム効率低下させる主張している。マイクロカーネルは通常アドレス空間義部プロセス間通信 (IPC)、プロセス管理といった最小限サービスだけを提供するハードウェア処理といった他の機能はマイクロカーネルで直接扱うことはない。マイクロカーネル支持派は、モノリシックカーネルでのエラーバグ)がシステム全体クラッシュ引き起こすという欠点指摘する。しかしマイクロカーネルでは、サーバクラッシュしてもそのサービス再起動することでシステム全体クラッシュを防ぐ可能性がある。しかし、現にLinuxなどのモノリシックカーネルは年単位安定動作している実績があり、このようなマイクロカーネルの利点どれほど重要かは疑わしいネットワーキングなどのカーネルサービスは「サーバ」と呼ばれるユーザ空間プログラムとして実装される。サーバ停止再起動するだけでOS更新可能である。例えネットワークサポートしていないマシンで、ネットワークサーバ起動する必要がないサーバ群やカーネルの間でデータやり取りする作業があるため、モノリシックカーネルにはないオーバヘッド生じ効率低下する。 マイクロカーネルの短所例え次のようなものがある。 全体としてメモリをより多く使用するインタフェースを持つソフトウェアの数が多く性能低下可能性がある。 サーバ群とカーネル間のメッセージングバグがあると、検出が困難である。 プロセス管理一般に非常に複雑になりうる。 使用状況によってはマイクロカーネルは不利になる単一用途システムでは動作するプロセス数が小さいため、マイクロカーネルがよく機能しプロセス管理複雑さもあまり問題にならない。 マイクロカーネル方式では、OSの他の部分通常のアプリケーションのように高水準言語で書くことができ、同一カーネル上で異なOS(のインタフェース)を使用するともできる。また動的にOS切り換えたり、複数OS同時に使用するともできる

※この「マイクロカーネル」の解説は、「カーネル」の解説の一部です。
「マイクロカーネル」を含む「カーネル」の記事については、「カーネル」の概要を参照ください。

ウィキペディア小見出し辞書の「マイクロカーネル」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「マイクロカーネル」の関連用語

マイクロカーネルのお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



マイクロカーネルのページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
デジタル大辞泉デジタル大辞泉
(C)Shogakukan Inc.
株式会社 小学館
IT用語辞典バイナリIT用語辞典バイナリ
Copyright © 2005-2024 Weblio 辞書 IT用語辞典バイナリさくいん。 この記事は、IT用語辞典バイナリの【マイクロカーネル】の記事を利用しております。
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのマイクロカーネル (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。
ウィキペディアウィキペディア
Text is available under GNU Free Documentation License (GFDL).
Weblio辞書に掲載されている「ウィキペディア小見出し辞書」の記事は、Wikipediaのカーネル (改訂履歴)、JavaOS (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。

©2024 GRAS Group, Inc.RSS