ノート:エロス (曖昧さ回避)
ノート:エロス (神話)において、本項目の移動の提案を行いました。ご意見をよろしくお願いいたします。--shikai shaw 2005年6月12日 (日) 07:37 (UTC)
The EROS Operating System
[編集]EROSはThe Extremely Reliable Operating System（極めて信頼性の高いオペレーティングシステム）の略。ペンシルバニア大学ジョンズ・ホプキンス(Johns Hopkins)を中心とするグループによる研究で開発されたオペレーティングシステムである。（プロジェクトはペンシルバニア大学からジョンズ・ホプキンス大学へ移行している。）ホプキンスのグループは「直交永続性を提供する小さくて安全なRTOSの実装。」という成果を上げた。EROSの研究を終えたホプキンスのグループは、EROSの欠点を解決すべくCoyotosの研究に着手する。またEROSの研究開発は終了しているが、Charlie Landauを中心とするCapROSプロジェクトにおいて、EROSのコードをベースに用いたOSの開発が行われている。外部リンクThe EROS Operating System、The CapROS Operating System --61.125.222.70 2008年5月8日 (木) 01:59 (UTC)
- 2008年5月13日現在のウィキペディアen:EROS (microkernel)英語版記事を機械翻訳したものをアップします。
EROS（極めて信頼性が高いオペレーティング・システムThe Extremely Reliable Operating System）はEROSグループ、 LLC. 、ジョンズ・ホプキンス大学とペンシルバニア大学によって開発されるオペレーティングシステムである。 面白い機能が自動的なデータとプロセス永続性、若干の事前リアルタイムのサポートとキャパビリティベースのセキュリティをインクルードする。 EROSは純粋に研究オペレーティング・システムであって、そして実世界使用で決して配置されなかった。 2005年の時点で、２つの継承システムen:CapROS と en:Coyotosに賛成して開発が止まった 。
重要な概念
[編集]EROSシステム（そしてその親類）の最優先のゴールは小さいコミュニケートしているコンポーネントの中にオペレーティング・システムレベルにおいて重大なアプリケーションの効率的な再構築に強力なサポートを提供することである。 それぞれのコンポーネントが保護されたインタフェースを介してだけ他のものとコミュニケートすることができて、そしてシステムの残りから隔離される。 「保護されたインタフェース」は、このコンテキストで、オペレーティング・システム（カーネル）の最も低いレベル部分によって強制される（の・もの・人）である。 カーネルは唯一のインフォメーションを１つのプロセスからもう１（つ・人）まで動かすことができるシステムの部分である。 それは同じくマシンの完全に信用する管理を持って、そして（もし適切だ建設されるなら）迂回されることができない。 EROSで、（それによって）１つのコンポーネントがもう１（つ・人）のサービスに名前をつけて、そしてそれに訴えるカーネルによって提供された機構はプロセス間通信（ IPC ）を使うキャパビリティである。 能力によって守られたインタフェースを強制することによって、カーネルはプロセスへのすべての伝達が意図的にエクスポートされたインタフェースによって到着することを保証する。 それは同じく、コンポーネントを呼び出すことが有効な能力を呼び出そうとするものと考えないなら、呼出しが可能ではないことを保証する。 １つのコンポーネントからもう１つまで、しばしば制限として既知のセキュリティポリシーを介してキャパビリティの伝播を限定することによって、キャパビリティシステムでの防護が達成される。
キャパビリティシステムが当然コンポーネントベースのソフトウェア構造を促進する。 この組織的なアプローチはオブジェクト指向プログラミングのプログラム言語概念に類似しているが、より大きい粒度において偶然起こって、そして継承のコンセプトをインクルードしない。 ソフトウェアがこのようにして再構成されるとき、いくつかの利益が出現する：
- 個別のコンポーネントはイベントループとして最も当然構造化されている。 このように一般に構造化されているシステムの例が（ DO-178B 空挺部隊システムと設備保証でのソフトウェア考察を見なさい）操縦系統をインクルードして、そして交換システムに電話をかける（ en:5ESS交換機を参照）。 イベント駆動型プログラミングが単純とロバストネスのために主にこれらのシステムのために選ばれる、そしてそれはライフクリティカルの、そしてミッションクリティカルなシステムで不可欠な属性である。
- コンポーネントがより小さくて、そして個々に検証可能になる、そしてそれは実装者がいっそう容易に欠陥とバグを認識するのに役立つ。
- 他のものからのそれぞれのコンポーネントの分離は、何かが壊れる、あるいはソフトウェアが行儀悪く振る舞うとき、偶然起こるかもしれない損害の範囲を制限する。
集合的に、これらの利益は測れるようにいっそう強靭な、そして保全性が高いシステムに導く。 en:SDS Sigma 7は電話交換機で元来使用のために設計されるハードウェアベースのキャパビリティシステムであった。 資格準拠した意匠が特にロバストネスの理由のために選ばれた。
多くのより以前のシステムと対照的な、EROSでリソースに名前をつけて、そして使うことに対して、キャパビリティは唯一のメカニズムである。 このようなシステムは時々純粋なキャパビリティシステムであると述べられる。 IBM AS/400は商業的に成功したキャパビリティシステムの例である、しかしそれは純粋なキャパビリティシステムではない。
純粋なキャパビリティアーキテクチャがよくテストされた、そして成熟した数学的な防御モデルによってサポートされる。 これらは公式に、もし正確に実装されるなら、資格準拠したシステムが安全にされることができることを実証するために使われた。 いわゆる「安全プロパティ」は純粋なキャパビリティシステムのために決着させることを示された（リプトン参照）。 単離の基本的な構成ブロックである制限は（EROS制限メカニズムを検証する]を参照）公式に純粋なキャパビリティシステムによって実施可能であると確かめられて、そしてEROS「コンストラクタ」と KeyKOS 「工場」によって実用的な実装に煮詰められる。 類似の検証が他のいかなるプリミティブ防護機構のためにも存在しない。 （ HRU を見なさい、しかし限定されたケース[1]の無限のセットのためにそれがもちろん証明可能であることに注意を払いなさい）一般的なケースに「安全」が数学上未解決であるという文献主張に重要な結果がある。 より大きい実用的な重要性について、プリミティブ防護メカニズムのすべてが現在の商品オペレーティング・システムで出荷されることに関して、安全は偽りであることを示された（ HRU 参照）。安全はどんなセキュリティポリシーの成功した施行にでも必要な前提条件である。 実際的な条件で、この結果は現在の商品システムを安全に保つことが原則として可能ではないことを意味する、しかし、それらが十分な注意を払って実装されるなら、資格準拠したシステムを安全に保つことは潜在的に可能である。 いずれのシステムも今までに成功裏に通り抜けられなかった、そしてそれらの分離メカニズムは成功裏に一度も内側攻撃者によって破られたことがない、しかしEROSあるいは KeyKOS インプリメンテーションが十分に注意深かったかどうかは知られていない。 コンポーネントの分離と防御が（それによって）決定的に達成された en:Coyotos プロジェクトの目標が実証するはずであるものがソフトウェア検証技術を適用する。L4マイクロカーネルファミリーの継承である L4.sec システムは資格準拠したシステムであって、そして際立ってEROSプロジェクトの結果によって影響を与えられた。 高性能な呼出しのEROSの仕事が L4 マイクロカーネル科と一緒にヨハン Liedtke の成功によって強く興味を起こさせられたときから、影響力は相互である。
歴史
[編集]EROSの主要なデベロッパーはジョナサン・シャピロであった。 彼は Coyotos の後ろに同じく推進力である、そしてそれはEROSオペレーティング・システムを越えて「進化の系譜(evolutionary step)」[2]である。
EROSプロジェクトはより以前のシステム、en:KeyKOS[3]のクリーンルーム再構築として1991年に始まった。 KeyKOS はキーロジック社によって開発されるオペレーティング・システムであって、そして Tymshare 社によって作られたより以前の GNOSIS （Great New Operating System In the Sky:空での素晴らしい新しいオペレーティング・システム）システムの仕事のダイレクト継続であった。 KeyKOS システムは今日（2006年）[要出典]複製されていないままでいる防御と信頼性の度を提供した。 1991年のキーロジックの残念な組織解散を取り巻いている実情はKeyKOSライセンスを執行できないようにした。 KeyKOS がいずれにしても人気が高い商品プロセッサ上で走らなかったので、判断は公的に入手できるドキュメンテーションからそれを再現するためにされた。
1992年後期にによる進化のステップ、プロセッサアーキテクチャがキャパビリティ理念の導入から（すでに）際立って変化していた、そしてコンポーネント - 構造化されたシステムが実用的であったことはもう明白ではなかったことは（すでに）明確になっていた。 同様に多数のプロセスと IPC に有利にはたらくマイクロカーネルベースのシステムがひどい効率忌避に直面していた、そして、もしこれらが成功裏に解決されることができたなら、不確実であった。 x86 アーキテクチャは明らかに最有力のアーキテクチャになっていた、しかし386そして486の上の高価なユーザー/スーパーバイザー遷移潜伏はプロセスベースの分離のために重大な忌避を引き起こした。 EROSプロジェクトは研究努力に変わっていた、そしてシャピロの学位論文研究のフォーカスになるためにペンシルバニア大学に移動した。 1999年までに、 IPC で直接その卓越したスピードのために知られている L4マイクロカーネルファミリと一緒に激しく競い合う効率であった高性能実装がペンティアムプロセッサのために実践された。 EROS制限メカニズムは安全なキャパビリティシステムのために一般的な形式モデルを作って（すでに）、プロセスで、公式に検証されていた。
2000年に、シャピロはジョンズ・ホプキンス大学でコンピュータサイエンスの教授[4]に合流した。 ホプキンスに、ゴールはどのようにEROSカーネルによって提供されたファシリティをアプリケーションレベルにおいて安全な、そして防御できるサーバーを建設するために用いるべきか示すことであった。 国防高等研究計画局と空軍研究所によって資金を供給されて、EROSが信用されたウインドウシステム、高性能な、防御できるネットワークスタックと安全な Web ブラウザの始まりの基盤として使われた。 それは同じく軽量の静的チェックの有効性を探究するために使われた。 ２００３年に、（顕著にEROSと L4 を含めて）同期的な IPC プリミティブに基づいてどんなシステムアーキテクチャにでも本質的な若干の非常に挑戦的なセキュリティ問題が発見された。 EROSの仕事が en:Coyotos を好感して止まった、そしてそれはこれらの問題を解決する。
2006年の時点で、EROSとその後継機は商品ハードウェア上で走るただ広く入手できるキャパビリティシステムである。
状況
[編集]EROSの仕事がオリジナルのグループによって止まった、しかし２つの継承システムがある。 en:CapROS システム[5]はEROSコードベースから直接ビルドすることである、他方 en:Coyotos システム[6]はEROSの構造上の欠損の若干を扱う継承システムであって、そして（研究として）完全に検証するオペレーティング・システムの可能性を探究している。 CapROS と Coyotos 両方が種々のコマーシャル実装でリリースされることを期待される。
関連項目
[編集]参考文献
[編集]- R. J. Lipton and L. Snyder. "A Linear Time Algorithm for Deciding Subject Security." Journal of the ACM, 24'(3):455--464, 1977.
- M. A. Harrison, W. L. Ruzzo and J. D. Ullman. "Protection in Operating Systems". Communications of ACM. 19(8):461--471, August 1976.
外部リンク
[編集]- 誤訳があるかもしれませんが適当に直して使ってくだされば幸いです。--61.125.222.70 2008年5月13日 (火) 14:12 (UTC)
- このノートページ自体がCategory:オペレーティングシステム等にカテゴライズされてしまうので、該当部分をコメントアウトしました。--203.95.50.137 2009年5月21日 (木) 16:31 (UTC)
- 私が「61.125.222.70 2008年5月13日 (火) 14:12 (UTC)」で、ここに投げた翻訳内容は、元記事の版がいつのものであるか自明的でないと著作権侵害になる可能性が高いらしいので、投稿がかえって迷惑になってしまったのではないかという気がしてきました。Wikipedia:翻訳のガイドラインによると、原文と訳文は差分で追えるようにしなければならないそうです。もしご迷惑になっているようでしたら一旦削除して仕切りなおしにしてくださっても結構です。--202.213.151.82 2009年11月16日 (月) 17:34 (UTC)