Microsoft Singularityについて何か書きたいと思います。 これは非常にクールなことであり、今日のITでは誰もがそれについて話している。 公式の出版物を読みたくない人のための特異点レビューはこちらです。

これは何ですか

特異点は、オペレーティングシステムの研究プロジェクトです。 これは、「もともと信頼性を重視したオペレーティングシステムをどのように作成しますか？」と言われた優秀な人々のチームです。

SlashdotやOSNewsのような人気のあるフォーラムの人々は、MicrosoftがWindowsを放棄してゼロから始めることを長年夢見てきた -不安や悪意のあるコード（マルウェア）の問題を克服するためです。 通常、これらすべての人々の夢は、WindowsをUNIXに移植するというアイデアを中心に展開しますが、これはくだらないアイデアであり、主な問題を解決するものではありません。 基本的な設計機能に起因する問題を解決したい場合は、設計から始める必要があります。 これは特異点で行われます。

信頼性はかなり広範な質問です。 少なくとも、これはアプリケーションがクラッシュせず、安全であることを意味します。 しかし、Singularityの開発は多くの分野をカバーしているという事実にもかかわらず、開発者には本格的なOSを作成するタスクはありません。たとえば、GUI開発には関与していません。

違いは何ですか？

実際に、これは私がここで話すことです。

特異点は、マイクロカーネル設計であり、高性能、単一アドレス空間、静的型検証、およびアクセス権の柔軟な管理です。

そうそう、前の文には恐ろしい学問用語がたくさんありました。 それらを理解してみましょう。 特異点は、チュートリアルの標準OS設計からはほど遠いため、簡単ではありません。

特異点- 高性能 。 実際、生産性はプロジェクトの目標ではありませんでしたが、開発者はそれなしでは開発が「クラウドに飛び込み」、完全に非商業化できることを理解するのに十分賢明でした。 これは、Microsoftがいつか実際の製品でこの開発を使用する予定であることを間接的に示しているため、高速にする必要があります（詳細は後ほど）。

そして特異点はマイクロカーネルです。 それが何であるかに今焦点を当てましょう。 他のことについては後で話します。 このすべてを既に認識している場合は、下にスクロールします。この場合、マイクロカーネルとは何か、なぜ低速と見なされるかを正確に知っていると想定します。

ええと...マイクロ何？

歴史的に、オペレーティングシステムの設計には2つの方法があり、異なるコストと利益の比率を使用して同じことを行う2つの方法がありました。小核またはモノリシックカーネルです。 ここで低レベルの設計について話していることに注意してください...これは、UIでタスクバーを使用するかドッキングするかには影響しません。

マイクロカーネル設計では、ファイルシステムやネットワークドライバーなどのサブシステムは、カーネル自体の外部の多かれ少なかれ通常のプログラムのように機能します（特殊なプロセッサモードで動作するという点で他のプログラムとは異なります）。 カーネルは、プロセス/スレッドを作成し、それらの間でメッセージを転送し、CPUリソースの割り当てなど、その他の小さなことのみを行います。 今日の真の小核はほとんど発見されていません。 ほとんどの場合、あなたもそれを実現することなく使用しました。 たとえば、QNXは、Ciscoルーターなどの組み込みアプリケーション向けに設計されたオペレーティングシステムです。 QNXは純粋なマイクロカーネルです。

愛人メモ

仮想メモリの概要を以下に示します。 コードがメモリから何かを読み取ると、CPUは内部的にアドレスを仮想アドレスからメモリコントローラーに送ることができる物理アドレスに変換します。 32ビットCPUでは、両方とも32ビットポインターであり、核開発者でない限り、ほとんどの場合、直接の物理アドレスは表示されません。 この変換は、MMU（メモリ管理ユニット）と呼ばれるプロセッサコンポーネントによって行われます-また、アクセス制御も実装します。 メモリは4キロバイトの「ページ」に分割され（Intel / AMDチップ内）、ページごとにマッピングが開始されます。 表示ページには、UNIX上のファイルと同じように、読み取り/書き込み/実行のアクセスビットがあります。

このメモリマッピングは、すべてのオペレーティングシステムのセキュリティの基礎です。 バグのあるプログラムがメモリ内の他のプログラムを台無しにすることはできません。また、メモリページのテーブルを更新できるのはカーネルだけであり、ハードウェアへのすべてのアクセスはカーネルを介して行われるため、プロセッサのユーザーモードで動作するプログラムは、カーネルが「興味深い」ことを行うことができませんこれは許可されません。 また、MMUではカーネルメモリを読み取ることができないため、アクセスできません。 また、スワップファイルを使用してディスクをRAMチップとして使用できることを意味します。プロセスアドレススペースの一部の表示をアンロードし、そこから読み取ったエラーをキャッチして、表示を再度ダウンロードします。

仮想メモリは素晴らしいことであり、過去13年間でコンピューターの信頼性が最大に向上したことの1つです。 Windows 3.1は、Windows 95とは異なり、これを使用しませんでした。そのため、多くの人がOSを更新しました。 マイクロカーネルの利点はここで明らかです-バグのあるカーネルコンポーネントはコンピューターをBSOD、別名「死のブルースクリーン」に送ることはできません-今日のように。 ファイルシステムがクラッシュした場合は、再起動してください！

モノリシック設計では、ファイルシステム、ドライバー、さらにはWebサーバーもカーネルに直接読み込まれ、特権プロセッサモードで動作します。 カーネルは、ユーザーモードプロセス用のメッセージ受け渡しシステムを引き続き提供しますが、他の場所では使用されません。 今日、一般的なサーバーまたはデスクトップOSはすべてWindows、Linux、MacOSのWindowsモノリシックです。 Linuxは常にモノリシックであり、Windows NTは元々マイクロカーネルであり、Machに基づいたMacOSは理論的にはマイクロカーネルであったことに注意してください。 しかし、私はそれを信じる人を誰も知りません。

オペレーティングシステムがマイクロカーネルまたはモノリシックであるかどうかを判断するのはおそらく難しいでしょう。なぜなら、それはバイナリの「yes / no」ロジックではないからです。たとえば、Linuxではグラフィックサブシステムは別のプロセス（X Server）で動作しますが、Windowsではそれはそうでした -しかし、今日ではありません。 いずれにしても、Linuxがマイクロカーネルではないと主張する人はいません。 優れた評価基準は、ファイルシステムがカーネルモードで動作するかどうかです。グラフィックシステムは灰色の領域にありますが、ファイルシステムはありません。

いずれにせよ、Singularityが小核設計を使用しているという事実は、奇妙なことに見えます。歴史的に学術環境では小核が勝っていましたが、主にパフォーマンスの問題により、モノリシックコアが常に市場で勝っていました。 これらの紛争は80年代に勃発しました- ここでは、トーバルズとタネンバウムの間の有名な紛争を読むことができます 。 そのため、一見すると、特異性は理論的にはクリーンであるが実際には使用できないものの別の学問的発展のように思えるかもしれませんが、そうではありません。

マイクロカーネルが遅いのはなぜですか？

マイクロカーネルは通常、プロセッサモード（カーネルモードでのユーザーモード、またはその逆）の切り替えのオーバーヘッドにより、モノリシックカーネルよりも低速です。 さらに、2つのユーザーモードプロセス間でプロセッサを切り替えるコスト（コンテキストスイッチング）もあります。

これらのコストは小さくても現実的であり、1秒あたり何百ものそのような切り替えを行うと、すべてのプロセッサの作業が前後の切り替えに削減されるという事実につながりますが、実際の作業に残された時間はありません。 そして、これらのコストを測定することは非常に困難ですが、Singularityチームはそれを行いました。

これらの切り替えに貴重な時間がかかるのは、CPUが通常とは異なるジョブを実行する必要があるためです。また、プロセッサはこの作業を行わずにほとんどの時間を費やすため、あまり最適化されていません。 これは、最近のx86チップの世代で変更されましたが、全体的にはすべてが同じままです。

たとえば、syscallを実行してカーネルに強制的に何かをさせるには、特別なプロセッサ命令を使用します。 これは通常Linuxでは「int 80」ですが、今日では、それをサポートするコアとプロセッサで「sysenter」オペコードを使用できます（ほとんどの人が使用できます）。 この場合、制御はコアに渡されます。 これは最新のコンピューターではかなり高速ですが、常にそうであるとは限りませんでした-たとえば、Windowsの初期バージョンではCPU例外をスローする方が割り込みを使用するよりもカーネルモードに入る方が速いことが判明したため、誤ったプロセッサー命令を使用していました（「公式」方法）。 Intelはそれを修正しました:)

コンテキストの切り替えはより高価です。 第一に、それが明らかにカーネルモードへの移行を引き起こし、またメモリマッピングテーブルの再構成が高速ではないためです。

これもまた珍しい操作であるため（x86チップで特別なレジスタを使用する必要があるため）高速ではありませんが、主にいわゆる「変換ルックアサイドバッファ」（TLB）のリセットが必要です。 これらのバッファーには、MMU要求の結果が格納されます。 実際、MMUがタスクに特化したハードウェアであっても、その使用は無料ではありません（コードにアクセスするたびにメモリアドレスの変換を行う必要があります（常に発生します）。ここでは、キャッシュが必要です。

このため、コンテキストスイッチングの費用を測定することは困難です。 CPUの基本的な設計機能のために、そこに何か価値があることはわかっています。 しかし、実際の価値は実行中のプロセスのコードによって塗りつぶされます。 コンテキストを切り替えた直後、コンピューターの実行速度がやや遅くなり、TLBが読み込まれると速度が上がります。

したがって、2つの相反する優先順位があります。 一方では、アドレス空間を分離するために仮想メモリを使用すると、プログラムを互いに分離することで信頼性が向上しますが（これは良いことですが）、一方で、パフォーマンスの損失を測定するのが難しくなります-これは悪いことです。 さらに悪いことに、プロセッサはときどき高速になりますが、コードの実行は高速になりますが、アドレス空間の操作は高速ではないため、今回はムーアの法則に頼ることができません。

メッセージング

マイクロカーネルは、異なるアドレス空間のプロセス間でメッセージを送信するという考えに基づいています。 そのため、ファイルを読み取るには、プログラムからファイルシステムサーバーにメッセージを送信する必要があります。 メモリにメッセージを形成し（これは高速）、syscallで「メッセージを送信」し​​ます（もう高速ではありません）。その後、カーネルはメッセージを独自のアドレス空間にコピーし（ややゆっくり）、コンテキストをファイルシステムサーバーに切り替えます（ゆっくり）カーネルモードを終了する前に、ファイルシステムサーバーのメモリにメッセージをコピーします。

ファイルシステムが探しているファイルを読み取るとき、この錫をすべて逆の順序で繰り返す必要があります。今回はデータを返信メッセージにコピーします...そしてメッセージの送信コストはサイズとともに増加するため、これは最初のリクエストよりもさらに遅いです！

モノリシックなデザインではまったく異なって見えます：リクエストを作成し（高速）、syscallを実行し（それほど高速ではありません）、ファイルシステムがデータを受信するまで待機し、その後カーネルがデータをアドレススペースに直接コピーします（または、 DMAを使用する場合）、ユーザーモードに制御を戻す...わあ、簡単で高速です！ ここでの欠点は、ファイルシステムがクラッシュすると、OS全体がBSODでクラッシュし、すべてが失われることです。

Windowsでのクラッシュの約80％は、曲がったドライバーが原因です。 したがって、バグのあるプログラムによるクラッシュを防ぐのと同じ方法で、ドライバーによるシステムクラッシュを防ぐことができれば、世界中のすべてのBSODの80％を防ぐことができます。 これはかなりクールです！ また、セキュリティメカニズムがドライバーで機能できることも意味します。 今日サードパーティのファイルシステムをインストールする場合、実際に何が得られるのか誰が知っていますか？ 自分でコードを確認してコンパイルするまで、コードを提供した人を信頼する必要があります。 これですべてが問題ない場合でも、新しいドライバーのバグがルートキットに穴を開け、セキュリティシステム全体を曲げることがあります:(

おそらく、学者が遅くても信頼できるソリューションを好んだのは驚くことではありません-デスクトップOS開発者は速くても不安定なソリューションを好んだのです。 しかし、彼らはそうしなかったとは思わないでください！ Windows NTは、純粋にマイクロカーネルソリューションとして開発されましたが、プロセス間通信が非常に最適化されていても、GUIと共にカーネルに降伏し、「移動」しました。

特異点

特異点は、「座って食べる」ことに成功します-マイクロカーネルのすべての利点と、モノリシックコアよりも高いパフォーマンスを実現します。 かっこいい！

どのように機能しますか？

特異性は、そのクリーンなマイクロカーネル設計に印象的で、従来のアプローチよりも30％高速で、モノリシックよりも10％高速です（重いファイルI / Oのベンチマークで）。 彼女はどうやってそれをしますか？

トリックは非常に簡単です-ハードウェアのメモリ保護を完全に放棄しました。 Singularityでは、すべてがカーネルモードで動作し、すべてが単一のアドレススペースで動作します。 つまり、MMUは何もしません。 そして、伝統的な意味での「プロセス」はありません。

もちろん、これが彼らがした唯一のことであれば、それはそれほど面白くないでしょう。 Windowsのクラッシュの80％は、カーネルエラーではなく、バグのあるドライバーが原因です（残りの20％はハードウェア障害が原因であると思われます）。 権限の昇格を可能にする無数の脆弱性は、ドライバーの不具合によって引き起こされます。 そのような脆弱性はそれぞれ「悪者」への贈り物です。 ソフトウェアのバグ保護は、マイクロカーネルを便利にするものです。

Singularityのプログラムは互いに分離されていますが、分離はシリコンではなく型理論を使用して完全にプログラム的に実行されます。 これは、SingularityプログラムがS＃と呼ばれ​​るC＃の子孫で書かれているために可能です（理論的には、.NETには任意の言語を使用できます-SingularityはC＃に追加された機能をほとんど使用しないため、他の言語ではこれらのわずかな変更のみが必要です） 。

おそらく、JavaやC＃のようなほとんどの現代言語では、メモリに直接アクセスできないことをご存知でしょう。 大まかに言って、Javaで同様のCコードを書くことはできません。

*((char *)0x1234) = ‘X’; // 1234

, . Java/C# -, , , . , , JVM/MSIL « », , , , / . — !

, . . , C , — Java/.NET ( C++) .

, , reflection () , .

JVM- . , JRE — .

Singularity — C#, C++ . . Microsoft — , .

Singularity — SIP, software isolated process « ». Singularity , -, , — .

SIP (heap), ( GC, , GC ) . SIP , ( KaffeOS), . , SIP. , SIP — , . , , GC , .

CPU — , , «». Singularity «» , SIP' , , SIP' . , / , C++ . SIP ( ), , , .

SIP' , . , GC SIP' — . syscall .

SIP' «». — , UNIX' , . , , — - . . SIP' ( , -) .

, . ? SIP' ?

, SIP (, CD), MSIL-. (just-in-time, JIT) , Java .NET. , . Singularity — . .

MSIL CPU , « I/O » « », — - , . , , , . , — CPU .

OS - . : , iTunes , , iPod. , -, , — , -, .

SIP' , ( ) SIP'. — ? , ?

Singularity . , .NET, XML-, SIP' , . . , , .

Singularity

, :

1. 80% Windows .
   
    
2. Linux , 7 , .
   
    
3. , « » , — — .
   
    
4. , . « ».

Singularity - , , — Sing#- (Sing# «» C#), MSIL-. SIP, . , C# — , «overflow» .

MSIL , , - . , - DLL, , , . DLL (Singularity.DriverRuntime



) , Microsoft «trusted computing base», - DRM, . DLL, , . IoPortRange



, IoIrqRange



( ..) - .

Singularity , . . , — , ? ?

Singularity , , . .NET — , . XML- ( , ) (compile-time transform), , . — HAL (hardware abstraction layer).

, Singularity , . , ( ) — . , , .

?

, - ( ?). , , DMA- , .

DMA — Direct Memory Access ( ) — , RAM, CPU. , , , . , DMA CPU, MMU, , DMA- . , . Singularity .

, DRM! , ! CPU, Intel AMD, -, ( ) IOMMU. , MMU — , / DMA . IOMMU, DMA. ( DRM-). , , , .

, , DMA- - «».

?

2001- Microsoft . , . — , , , . Microsoft unit-, , . Microsoft. ?

, , . , . , , . $250 , «OK» . .

. , — .

, , : «, , “ ”, DMA, ( , , )». , ? . , , . BSOD, . , , — , .

, ( Singularity , SIP'), — . ? , . ( DoS' - ? ). , , - , , . , Microsoft, .