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

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

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

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

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 ++のようなものがしばしば推奨されます。

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

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

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

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