EROS（マイクロカーネル）
エロス
開発者ペンシルベニア大学ジョンズ・ホプキンス大学EROSグループLLC
書かれたC
OSファミリー能力ベース
作業状態製造中止
初回リリース1991 （1991年）
最新リリース最終 / 2005 （2005年）
マーケティングターゲット研究
入手可能な英語
更新方法ソースコードからコンパイルする
サポートされているプラ​​ットフォームIA-32
カーネルタイプリアルタイムマイクロカーネル
デフォルトのユーザーインターフェースコマンドラインインターフェース
先行キーコス
後継者キャップロス

EROS（Extremely Reliable Operating System）は、1991年にペンシルベニア大学、その後ジョンズ・ホプキンス大学、そしてEROS Group, LLCによって開発されたオペレーティングシステムです。データとプロセスの自動永続化、予備的なリアルタイムサポート、そして機能ベースのセキュリティといった機能を備えています。EROSは純粋に研究目的のオペレーティングシステムであり、実用化されたことはありませんでした。2005年をもって開発は中止され、後継システムであるCapROSが開発されました。

重要な概念

EROS システム (およびその関連システム) の最も重要な目標は、重要なアプリケーションを小さな通信コンポーネントに効率的に再構築するための強力なサポートをオペレーティング システム レベルで提供することです。各コンポーネントは、保護されたインターフェースを通じてのみ他のコンポーネントと通信でき、システムの残りの部分から分離されています。ここでの保護されたインターフェースは、オペレーティング システムの最下位レベル部分であるカーネルによって強制されるインターフェースです。これは、プロセス間で情報を移動できるシステム部分のみです。また、マシンを完全に制御し、(適切に構築されていれば) バイパスすることはできません。EROS では、あるコンポーネントが別のコンポーネントのサービスに名前を付けて呼び出すカーネル提供のメカニズムは、プロセス間通信(IPC)を使用する機能です。機能保護インターフェースを強制することにより、カーネルは、プロセスへのすべての通信が意図的にエクスポートされたインターフェースを介して到着することを保証します。また、呼び出し元のコンポーネントが呼び出されるコンポーネントに対する有効な機能を保持していない限り、呼び出しが不可能であることも保証します。機能システムにおける保護は、多くの場合、制限と呼ばれるセキュリティ ポリシーを通じて、あるコンポーネントから別のコンポーネントへの機能の伝播を制限することによって実現されます。

ケイパビリティシステムは、コンポーネントベースのソフトウェア構造を自然に促進します。この組織化アプローチは、プログラミング言語におけるオブジェクト指向プログラミングの概念に似ていますが、より粒度が高く、継承の概念は含まれていません。このようにソフトウェアを再構築すると、いくつかの利点が生まれます。

  • 個々のコンポーネントは、イベントループとして最も自然に構造化されます。このように構造化されるシステムの例としては、航空機の飛行制御システム（DO-178B「航空機搭載システムおよび機器認証におけるソフトウェアの考慮事項」も参照）や電話交換システム（5ESSスイッチを参照）などが挙げられます。これらのシステムでは、ライフクリティカルおよびミッションクリティカルなシステムにおいて不可欠な特性であるシンプルさと堅牢性のために、イベント駆動型プログラミングが主に選択されています。
  • コンポーネントが小さくなり、個別にテストできるようになるため、欠陥やバグをより簡単に分離して特定できるようになります。
  • 各コンポーネントを他のコンポーネントから分離することで、何か問題が発生した場合やソフトウェアが誤動作した場合に発生する可能性のある損害の範囲を制限します。

これらの利点を総合的に活用することで、システムの堅牢性とセキュリティは目に見える形で向上します。Plessey System 250は、もともと電話交換機向けに設計されたシステムであり、堅牢性を重視して機能ベースの設計が採用されました。

EROSでは、多くの従来のシステムとは異なり、リソースの命名と使用はケイパビリティによってのみ行われるため、純粋ケイパビリティシステムと呼ばれることもあります。一方、IBM iは商業的に成功したケイパビリティシステムの一例ですが、純粋ケイパビリティシステムではありません。

純粋ケイパビリティアーキテクチャは、十分にテストされ成熟した数学的セキュリティモデルによって支えられています。これらのモデルは、ケイパビリティベースシステムが正しく実装されれば安全にできることを正式に実証するために用いられてきました。いわゆる「安全性」は、純粋ケイパビリティシステムにおいて決定可能であることが示されています（Lipton参照）。分離の基本的な構成要素である閉じ込めは、純粋ケイパビリティシステムによって強制可能であることが正式に検証されており[ 1 ]、EROSコンストラクタとKeyKOSファクトリによって実用的な実装にまで簡略化されています。他のプリミティブな保護メカニズムには、これに匹敵する検証は存在しません。文献には、一般的なケースにおいて安全性は数学的に決定不可能であることを示す基本的な結果があります（ HRU参照。ただし、もちろん、制限されたケースの無限集合に対しては証明可能であることに留意してください[ 2 ] ）。より実用的な観点から重要なのは、現在のコモディティオペレーティングシステムに搭載されているすべてのプリミティブな保護メカニズムにおいて、安全性が偽であることが示されていることです。安全性は、あらゆるセキュリティポリシーを効果的に強制するための必須の前提条件です。実用的には、この結果は、現在のコモディティシステムのセキュリティ確保は原理的には不可能であるが、十分な注意を払って実装されていれば、ケイパビリティベースのシステムのセキュリティ確保は潜在的に可能であることを意味します。EROSもKeyKOSもこれまで侵入に成功した例はなく、また、その分離メカニズムが内部攻撃者によって破られた例もありませんが、これら2つの実装が十分に注意を払われていたかどうかは不明です。Coyotosプロジェクトの目標の一つは、ソフトウェア検証技術を適用することで、コンポーネントの分離とセキュリティが確実に達成されていることを実証することでした。

L4マイクロカーネルファミリの後継であるL4.secシステムは、ケイパビリティベースのシステムであり、EROSプロジェクトの成果から大きな影響を受けています。EROSにおける高性能呼び出しに関する取り組みは、L4マイクロカーネルファミリにおけるJochen Liedtke氏の成功に強く影響を受けたため、その影響は相互的です。

歴史

EROSの主任開発者はジョナサン・S・シャピロでした。彼はまた、 EROSオペレーティングシステムの「進化の一歩」 [ 3 ]であったCoyotosの推進力でもありました[ 4 ] 。

EROSプロジェクトは、1991年に、以前のオペレーティングシステムであるKeyKOSのクリーンルーム再構築として開始されました。KeyKOSはKey Logic社によって開発され、Tymshare社が開発したGNOSIS（Great New Operating System In the Sky ）システムの直接的な継続開発でした。1991年のKey Logic社の倒産に至った経緯により、KeyKOSのライセンス供与は現実的ではありませんでした。KeyKOSは一般的な汎用プロセッサでは動作しなかったため、公開されているドキュメントに基づいて再構築することが決定されました。

1992 年後半までに、プロセッサ アーキテクチャはケイパビリティの概念の導入以降大きく変化し、コンポーネント構造のシステムが実用的であることはもはや自明ではなくなったことが明らかになりました。同様に多数のプロセスと IPC を好むマイクロカーネルベースのシステムは、深刻なパフォーマンス上の課題に直面しており、これをうまく解決できるかどうかは不透明でした。x86 アーキテクチャが支配的なアーキテクチャとして台頭しつつありましたが、386および486におけるユーザー/スーパーバイザ遷移の遅延が、プロセス ベースの分離にとって深刻な課題となっていました。EROS プロジェクトは研究活動へと変わり、ペンシルバニア大学に移され、シャピロの博士論文研究の中心となりました。1999 年までに、 Pentiumプロセッサ向けの高性能実装が実証され、 IPC での並外れた速度で知られるL4 マイクロカーネル ファミリと直接競合するパフォーマンスを実現しました。EROS の閉じ込めメカニズムは正式に検証され、その過程で、セキュア ケイパビリティ システムの一般的な形式モデルが作成されました。

2000年、シャピロはジョンズ・ホプキンス大学のコンピュータサイエンスの教授に加わった。ホプキンス大学での目標は、EROSカーネルが提供する機能を利用して、アプリケーションレベルで安全で防御可能なサーバーを構築する方法を示すことだった。国防高等研究計画局と空軍研究所の資金提供を受けたEROSは、信頼できるウィンドウシステム[ 5 ] 、高性能で防御可能なネットワークスタック[ 6 ] 、そして安全なウェブブラウザの始まりの基盤として使われた。また、軽量の静的チェックの有効性を調査するためにも使われた[ 7 ] 。2003年、同期IPCプリミティブ（特にEROSとL4を含む）に基づくシステムアーキテクチャに固有の、非常に困難なセキュリティ問題がいくつか発見された[ 8 ]。これらの問題はCoyotosによって解決されたため、EROSの開発は中止された。

2006 年現在、EROS とその後継システムは、市販のハードウェア上で実行される唯一の広く利用可能な機能システムです。

状態

EROSとCoyotosのオリジナルグループによる作業は中止されましたが、後継システムが存在します。[ 4 ] EROSの後継であるCapROS（Capability Based Reliable Operating System）は、オープンソースの商用指向のオペレーティングシステムです。[ 9 ]

参照

参考文献

  1. ^ Shapiro, Jonathan S.; Weber, Samuel (1999年10月29日). EROS閉じ込めメカニズムの検証(PDF) . 2000 IEEE Symposium on Security and Privacy. Berkeley, CA, USA. doi : 10.1109/SECPRI.2000.848454 .
  2. ^ Lee, Peter. 「Proof-Carrying Code」 . 2006年9月22日時点のオリジナルよりアーカイブ。
  3. ^シャピロ、ジョナサン（2006年4月2日）「コヨトスとEROSの違い：簡単な要約」 。2012年7月31日時点のオリジナルよりアーカイブ。
  4. ^ a b Shapiro, Jonathan S. (2009年4月7日). 「Coyotosの現状」 . coyotos-dev (メーリングリスト). 2014年7月24日時点のオリジナルよりアーカイブ。2022年3月16日閲覧。Coyotosの作業は数ヶ月前に停止しており、再開される可能性は低い。
  5. ^ Shapiro, Jonathan S.; Vanderburgh, John; Northup, Eric; Chizmadia, David (2004). EROS Trusted Window System の設計(PDF) . 第13回 USENIX セキュリティシンポジウム. 米国カリフォルニア州サンディエゴ.
  6. ^ Sinha, Anshumal; Sarat, Sandeep; Shapiro, Jonathan S. (2004).ネットワークサブシステムの再構築：高性能で防御力の高いネットワークサブシステム(PDF) . 2004 USENIX 年次技術会議. ボストン, マサチューセッツ州, 米国.
  7. ^ Chen, Hao; Shapiro, Jonathan S. 「ビルド統合型静的チェックを用いた正確性不変条件の保持」(PDF) 。 2016年3月3日時点のオリジナル(PDF)からのアーカイブ。
  8. ^ Shapiro, Jonathan S. (2003).同期IPC設計における脆弱性(PDF) . 2003年セキュリティとプライバシーに関するシンポジウム. 米国カリフォルニア州バークレー. doi : 10.1109/SECPRI.2003.1199341 .
  9. ^ Chakraborty, Pinaki (2010). 「研究目的のオペレーティングシステム – 広範な調査」GESJ: コンピュータサイエンスと電気通信. 3 (26). ISSN 1512-1232 . 

ジャーナル

  1. リプトン, RJ; スナイダー, L. (1977年7月). 「被験者のセキュリティを決定するための線形時間アルゴリズム」 . ACMジャーナル. 24 (3): 455– 464. doi : 10.1145/322017.322025 . S2CID  291367 .
  2. Harrison, Michael A. ; Ruzzo, WL; Ullman, Jeffrey D. (1976年8月). 「オペレーティングシステムにおける保護」 . Communications of the ACM . 19 (8): 461– 471. doi : 10.1145/360303.360333 . S2CID  5900205 .
「 https://en.wikipedia.org/w/index.php?title=EROS_(microkernel)&oldid=1259675217」から取得