マネージコードを実行する最小限のカーネルを使用する場合の潜在的な落とし穴は何ですか?


14

マネージコードインタープリター/ランタイムとして機能する非常に小さなネイティブの下位カーネルと、非ネイティブマシン言語(Javaバイトコード、CILなど)にコンパイルされた上位の上位カーネルに基づいてオペレーティングシステムを構築するとします。同様のオペレーティングシステムの例は、SingularityCosmosです。

純粋にネイティブなソリューションとは対照的に、この種のインフラストラクチャを備えたOSを作成する際に、どのような落とし穴と開発上の課題が存在しますか?

回答:


8

言語に応じて、多くの開発上の課題があります。

  1. ポインター:言語にポインターがない場合、比較的簡単なタスクを実行するのは困難です。たとえば、ポインターを使用して、画面に印刷するためにVGAメモリに書き込むことができます。ただし、マネージ言語では、同じことを行うために何らかの種類の「プラグ」(C / C ++から)が必要になります。

  2. アセンブリ: OSには常に何らかのアセンブリが必要です。C#やJavaなどの言語は、C / C ++とは異なり、C#やJavaではうまく機能しません。CまたはC ++では、多くのタスクに非常に役立つインラインアセンブリを使用することもできます。これが必要なケースは多数あります(x86の例):GDTのロード、IDTのロード、ページングの有効化、IRQのセットアップなど。

  3. コントロール: Cosmosのようなものを使用している場合、完全にコントロールすることはできません。Cosmosはマイクロカーネルであり、本質的に「カーネル」を「ブートストラップ」します。本当に必要な場合は、コスモスのようなものをゼロから実装できますが、それには長い時間がかかります。

  4. オーバーヘッド:マネージ言語では、CまたはC ++に比べてかなりのオーバーヘッドがあります。Cosmosのようなものは、C#hello worldカーネルを実行する前に多くのことを実装する必要があります。Cでは、実際にセットアップする必要はありません。C ++には、C ++の機能の一部を使用するために実装する必要があるものがいくつかあります。

  5. 構造: C / C ++には、多くのマネージ言語にはない構造があります。そのため、構造のようなものを持つ何らかの方法を実装する必要があります。たとえば、C / C ++でIDT(割り込み記述子テーブル)をロードする場合、(packed属性を持つ)構造体を作成し、x86 ASM命令lidtを使用してロードできます。マネージド言語では、これは非常に困難です...

マネージ言語は構文的には簡単ですが、多くのOSに関連するものはあまり適していません。それは、それらが使用できないという意味ではありませんが、C / C ++のようなものがしばしば推奨されます。


この答えはかなり弱いです。ポインターなしでは実行できない「比較的簡単なタスク」とは何ですか(小さな基盤を除く)。組み立てが必要な部品は何ですか?どのようなコントロールが不足していますか?オーバーヘッドについての声明は何に基づいていますか?マネージ言語で構造を持たないのはなぜですか?
ジル「SO-悪であるのをやめる」14

1.マネージ言語がVGAメモリにアクセスする機能を提供しない理由はありません。プリミティブ(メモリ管理プリミティブ)として提供する必要があるのは、マッピング/マッピングのみです。2.いくつかのタスクの切り替え(レジスタの保存など)は通常、アセンブリコードとして実行する必要がありますが、非常にローカライズされており、マネージ言語でOSの99%を使用することに対する議論ではありません。MMUの操作は、メモリ管理プリミティブです。4. Cもセットアップが必要です(スタックとヒープをセットアップします)。管理言語にはもう少しセットアップが必要ですが、質的な違いはありません。
ジル「SO-悪であるのをやめる」14

@Gilles、質問はマネージド言語を使用するための開発上の課題は何ですか。これらは、しかし、あなたはまだ成功し、このような課題を克服することができます...発達課題している
MMK

5

マネージコードによって拡張可能なシステムのセキュリティを評価する方法についてほとんど知られていないと主張する(競合するマイクロカーネルテクニックに取り組んでいる研究者による)と聞いたことがあります。

問題は、セキュリティホールを引き起こす可能性のあるバグの種類が、セキュリティ研究者が慣れているものとは非常に異なることです。従来のマイクロカーネルでは、カーネルのすべてのドライバーとその他のサブパーツは、異なるアドレススペースで実行することで互いに分離されます。タイプチェックマネージコードを介して分離が実装されているマイクロカーネルでは、サブサービスを使用する必要があるたびにアドレススペースを切り替えることによる膨大なオーバーヘッドを回避できますが、トレードオフは分離メカニズムの評価がより困難になることです。

マネージ言語で記述されたカーネルの特定の部分(デバイスドライバーなど)は、型チェッカーがドライバーが安全であり、型チェッカーにバグがないという場合にのみ安全です。したがって、型チェッカーはカーネルコアの一部です。実際には、型チェッカーは従来のマイクロカーネルコアよりもかなり大きく複雑です。これは、攻撃対象領域が潜在的に大きいことを意味します。

従来のマイクロカーネル分離技術とマネージコードベースの分離技術の信頼性が本当に高いのか低いのかはわかりません。ここにはブートストラップの問題があります。マネージコード分離手法が広く使用されるまで、それらが安全でない頻度を知ることはできません。しかし、それらがどれほど安全でないかを知らなければ、セキュリティが重要な状況でそれらを展開することは困難です。


それは素晴らしい点です。
アダムマラス14

これらの議論は非常に奇妙だと思います。(確かに、正式な方法の背景に偏っているかもしれませんが、これが私の意見の唯一の根拠ではありません。)タイプチェッカーは、マイクロカーネルとMMUに比べてそれほど複雑ではありません。たとえば、CoqのマイクロカーネルはOCamlの約14kLoCです。マイクロカーネルよりも大きいですが、それほど大きくはなく、ほとんどのカーネル(Cまたはアセンブラーなし)よりエラーの少ない言語で記述されています。型チェッカーは、特に微妙なバグである競合状態の影響を受けません。
ジル 'SO-悪であるのをやめる' 14

マネージコードを使用すると、特定のクラスのバグを処理する機会が増えます。たとえば、情報フロー分析では、サイドチャネルがないことを証明できます(多くの作業が必要になる可能性があり、どの程度行われたかはわかりませんが、原則として実行可能です)が、ハードウェア分離ではテストのみが可能ですあなたが考えたサイドチャネル。
ジル「SO-悪であるのをやめる」14

実際には、分離を提供するいくつかの仮想マシンがEAL5以降で認定されています。ヨーロッパ人の場合、クレジットカードなどのスマートカードで使用されるため、財布に入れておくとよい2つの例を次に示します。MULTOSJava Cardオープンプラットフォーム。セキュリティ評価コミュニティでは、MMUの分離がEAL2を超える可能性があるという多くの疑問を耳にしました。
ジル「SO-悪であるのをやめる」14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.