JP2009514099A

JP2009514099A - 分離されたエクステンションおよびデバイスドライバの構成

Info

Publication number: JP2009514099A
Application number: JP2008537770A
Authority: JP
Inventors: シー．ハントガレン; アール．ラルスジェームズ; エー．ファンドリッチマヌエル; ハドソンオリオン; ピー．レビスティーブン; スティーンスガードビャルネ; アール．タルディティデイビッド; スピアーマイケル; カービンマイケル; アバディマーティン; エイケンマーク; バーラムポール; ウォッバーテッド; ジルブライアン; ハウブリッツェルクリス; マーフィーニック
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-10-26
Filing date: 2006-10-16
Publication date: 2009-04-02
Anticipated expiration: 2026-10-16
Also published as: EP1952251A4; JP5009299B2; KR20080070634A; RU2008116714A; BRPI0618027A2; US8074231B2; KR101331361B1; RU2443012C2; EP1952251A1; US20070094673A1; WO2007050364A1

Abstract

アプリケーション、エクステンション、デバイスドライバ（３００）、及びソフトウェアシステムの他コンポーネントの構成要件を記述、及び／又はそれらに対応する１又は複数の実装につき、本明細書に記述する。

Description

本発明は、分離されたエクステンションおよびデバイスドライバの構成に関する。

オペレーティングシステム等のソフトウェアシステムには、一般に様々なタスクを行うための予め定義されたソフトウェアモジュールのセットが装備されている。これらのモジュールは全て、同じように予め定義されたセットの一部であるのでお互いに関連している。

しかしながら、追加の機能性及び／又はカスタマイズがしばしば必要になる。言い換えれば、機能性は「拡張」される。一般にソフトウェアシステムは、新しいソフトウェアモジュール又はプロセスを動的に追加することで拡張を可能にしている。この追加はしばしば「エクステンション」又は「プラグイン」と呼ばれる。従来のシステムにおけるエクステンション又はプラグインの共通の例には、これに限定されないが、オペレーティングシステム用デバイスドライバ、データベースの拡張ストアードプロシージャ、ウェブブラウザのプラグイン及びＡｃｔｉｖｅＸ（商標）コントロール、ウェブサーバのＩＳＡＰＩコンテンツ及びフィルタエクステンション、ユーザインタフェースシェル用シェルエクステンション等が含まれる。エクステンションにより追加された機能性は、ハードウェア装置の最新版に対するウィルススキャナへの簡単なサポートからｅメールクライアントのワークフローツールに至るまで多岐に渡る。ところが、エクステンションを統一する従来のアプローチには問題がある。

例えば、従来のオペレーティングシステム（「ＯＳ」）は、実行可能命令のセットをカーネル保護ドメインにロードすることによりエクステンションをロードする。一旦ドライバがこのアドレス空間にインストールされると、従来のカーネルはロードされたエクステンションがコンピューティングシステム内の任意の（又は全ての）ハードウェアにアクセスすることを防ぐことはできない。従って、不正な形式の又は悪質なエクステンションはＯＳのカーネルに大きな損害をもたらすことがある。

デバイスドライバはオペレーティングシステム内で見られるエクステンションの１つの種類である。デバイスドライバはオペレーティングシステムを拡張して、特定のデバイス又はデバイスのクラスにアクセスするソフトウェアモジュールである。例えば、ＩＤＥドライバは、ＩＤＥストレージコントローラに取り付けられたディスクドライブにオペレーティングシステムがアクセスできるようにする。デバイスドライバは、特定ベンダのストレージコントローラ等の特定のハードウェアに話しかけるマシンからの、ディスクストレージの読み取りや書込みブロック等の、オペレーティングシステムまたはアプリケーションが理解できる共通の機能性を抽象化するといった重要な機能を行う。デバイスドライバは物理デバイスに頻繁にアクセスする一方、仮想リソースにもアクセスできること、又はデバイスドライバをレイヤ化してストレージコントローラのデバイスドライバ上にある圧縮ドライバ等の追加機能性を追加できることを当業者は認識するであろう。

ユーザが、ホットスワップ及び電力管理等の豊富な特徴を期待するようになってきたので、過去１０年でデバイスドライバはかなり複雑なものになった。従来のオペレーティングシステムの多くは様々な方法で応答してはいるが、根本的にはこれらのシステムの備えるドライバモデルは１０年前と同じである。

エクステンションと同じように、従来のオペレーティングシステム（ＯＳ）は実行可能命令をカーネル保護ドメインにロードすることによりデバイスドライバをロードする。一旦ドライバがそのアドレス空間にインストールされると、従来のカーネルはロードされたドライバがコンピューティングシステム内のいずれかの（又は全ての）ハードウェアにアクセスすることを防ぐことはできない。

これらのドライバは一般に直接ハードウェアにアクセスするように低レベルのプリミティブで書かれているので、従来のカーネルは、ドライバが適切なハードウェアリソースだけを使用していることをめったに検証しない。その代わり、従来のカーネルは、ドライバはそれが役に立つことを要求するデバイスのためのハードウェアにアクセスするだけであろうと信頼する。更に、ドライバがアクティブなプロセスに割当てられているメモリ、又は従来のカーネル内部の他のコンポーネントに割当てられているメモリに留意するように、ドライバが正しく構成されていることを従来のカーネルが保証できないことがしばしばある。

従って、従来のドライバはＯＳの中では最も信頼性の低いコンポーネントに属している。一番良く知られている従来のＯＳにおいて原因の突きとめられたクラッシュの８５％はドライバに起因すると指摘するレポートもある。知名度の余り高くない従来のＯＳのドライバは、カーネル中の他の実行可能命令よりも７倍バグを含む可能性があると指摘するレポートもある。

アプリケーション、エクステンション、デバイスドライバ、及びソフトウェアシステムの他のコンポーネントの構成要件を記述及び／又はそれらに対応する１又は複数の実装について本明細書にて記述する。

この概要は、以下にさらに記述する詳細な説明を簡潔な形式で選択した概念を紹介するためのものである。この概要は、クレーム主題の重要な特徴又は本質的な特徴を特定することを意図しておらず、またその範囲を判定する補助として使用することも意図していない。

図面は全て、同じ要素及び特徴を参照する際には同じ数字を使用する。

アプリケーション、エクステンション、デバイスドライバ、及びソフトウェアシステムの他のコンポーネントの構成要件を記述及び／又はそれらに対応する技術を以下に説明する。

従来のエクステンション（例えば、デバイスドライバ）は、入力／出力（Ｉ／Ｏ）、メモリ、ビデオ、音声、割込み要求（ＩＲＱ）ライン、又は他のハードウェア等のコンピューティングリソースに直接アクセスするための実行可能命令を含む。従来のエクステンションとは異なり、本明細書に記述する１又は複数の実装に従って生成されたエクステンション（例えば、デバイスドライバ）は、１又は複数のローカルアクセスオブジェクトを介してコンピューティングリソースにアクセスするが、それはコンピューティングリソースにゲートウェイ又はブリッジを提供するオブジェクト（例えば１又は複数のデータ構造を持つ実行可能命令）である。

１又は複数の記述した実装では、エクステンションはこれらのリソースへの要求を含む構成要件を特定する、埋め込まれたメタデータを含む。オペレーティングシステム（ＯＳ）はこのメタデータに基づいてエクステンションのコンピュータリソース要求を判定する。ＯＳは、必要とされるリソースを割り当て、エクステンションをプロセスの外部のコンピューティングリソースに接続するために必要な実行可能命令を（ローカルアクセスオブジェクトの形式で）提供する。

この新たな分業はエクステンションのホスト（デバイスドライバの１又は複数の実施形態におけるＯＳ）に、全ての構成要件を検証し、エクステンションによりＩ／Ｏ又はＩＰＣリソースへのアクセスすべてを制御する能力を提供する。

［ソフトウェア分離プロセス］
コンピュータサイエンスの領域、特にオペレーティングシステムの技術では、「ソフトウェアプロセス」（又は単に「プロセス」）という用語がよく知られている。アプリケーションはしばしば１又は複数のプロセスで構成される。オペレーティングシステム（ＯＳ）はコンピュータ上で実行する１又は複数の個別のプロセスを認識、更に実際には管理、監督している。

本明細書では、プロセスは実行可能命令を有する。プログラムモジュールもまた実行可能命令を有する。１又は複数のプロセスはプログラムモジュールに基づいて実行できる。

本明細書では、エクステンションはプログラムモジュールとして記述できる。さらにデバイスドライバはエクステンションの一例である。本明細書に記述した１又は複数の実施形態は、分離されたプロセスを介して実施できる。分離されたプロセスのコンテキストは、図１のコンテキストに記述する。

本明細書では、１又は複数の実装がソフトウェア分離プロセス（ＳＩＰ）抽象化モデルの構成を提供及び／又はサポートするＯＳモデル上で動作するように記述されている。ＳＩＰはプログラムの要素又はシステムをカプセル化して、情報隠蔽、故障分離、及び強力な干渉を提供する。ＳＩＰはオペレーティングシステム及びアプリケーションソフトウェア全般で使用されている。

図１は、ＳＩＰ構築のための動作シナリオを示す。プロセス構築アーキテクチャ１００を、コンピュータ１２０上で格納され及び／又は実行されるオペレーティングシステム１１０の一部として示している。プロセス構築アーキテクチャ１００は、図１に示すようにオペレーティングシステムの一部としてもよい。あるいは、プロセス構築アーキテクチャ１００の全て又は一部をオペレーティングシステムから分離してもよいが、オペレーティングシステムとは依然協調して稼働している。

プロセス構築アーキテクチャ１００は、拡張コンポーネントのセットにより編集される構成コンポーネントの動的なセットから、コンピュータのワーキングメモリの中でプロセスを構築する。一旦構築されると、アクティブなプロセスの実行可能命令は固定される。一旦固定されると、アクティブなプロセスは新たなプロセッサ実行可能命令を普通は実行しない。そうするためには、一般にプロセスは、その一部として新しい実行可能命令で新たに再構築されるか、又は新しいアドオンプロセスが生成される。

構成コンポーネント及び拡張コンポーネントの動的なセットは、一般にコンピュータ記憶装置に格納されたロードモジュールのセットとして明示される。１又は複数の様々なプロセスの特性（例えば、保全性、セキュリティ、信頼性、可用性、リソース用法分析、完全性分析、及び／又は安定性）に関する分析が行われ、同様に様々な望ましい最適化が行われる方法で、プロセス構築アーキテクチャ１００は、プロセスを構築する。

コンピュータ１２０は、ロードモジュール１２４のセット及びワーキングメモリ１３０を格納するコンピュータ記憶装置１２２（例えば、ハードドライブ、ＲＡＩＤシステム等）を含む。図１の例では、プロセス構築アーキテクチャ１００は、ワーキングメモリ１３０に格納されるプロセス１４０を構築する。ここで示すように、プロセス１４０はロードモジュール１２４から構築されており、それはプロセスの拡張コンポーネントにより編集されるプロセスの構成コンポーネントを明示している。

プロセス１４０はプロセスマニフェスト１４２を有し、それはプロセス１４０の最終的なコンテンツを定義する。この最終的なコンテンツの一部は、プロセスの拡張コンポーネントにより編集されたプロセスの構成コンポーネントを含む。ここで示すように、プロセスマニフェスト１４２は、それが構成を記述する（プロセス１４０等の）プロセスと直接関連付けられている。

プロセスを構築する場合、プロセス構築アーキテクチャ１００は、以下の機能コンポーネントを１又は複数使用することができる。機能コンポーネントとは、プロセスマニフェストコンポーザ１５０、型付きコード表現クリエータ１５２、型付きコード表現アップデータ１５４、オプティマイザ１５６、型付きコード表現コンバータ１５８、プロセス間干渉エリミネータ１６０、及び固定アイデンティティクリエータ１６２である。図１ではこれらの機能コンポーネントは互いに別個のものとして示されているが、これらの機能コンポーネントの１又は複数の機能性を結合することもできる。

「双方向メッセージ導管を使用したプロセス間通信（Ｉｎｔｅｒ−ＰｒｏｃｅｓｓＣｏｍｍｕｎｉｃａｔｉｏｎｓＥｍｐｌｏｙｉｎｇＢｉ−ｄｉｒｅｃｔｉｏｎａｌＭｅｓｓａｇｅＣｏｎｄｕｉｔｓ）」アプリケーションは、ＳＩＰ（ＯＳも同様であるが）間で使用可能なプロセス間通信をサポートするＯＳモデルのコンポーネントを開示している。

ＳＩＰについては、カーネルの外部の実行可能命令は全てＳＩＰ中で実行し、強く型付けされた通信チャネルを介して他のＳＩＰと通信を行う。ＳＩＰは閉じた環境であり、データ共用又は動的コードローディングを許可していない。ＳＩＰは従来のＯＳプロセスとは多くの点で異なる。

新しいカーネル（本明細書で記述した実装をサポートしてオペレーティングシステム２１０で表わされる）は、殆どすべてが安全な実行可能命令からなり、ＳＩＰ内で実行する残りのシステムは、デバイスドライバ、システムプロセス、アプリケーションを含む検証可能な形で安全な実行可能命令からなる。信頼できない実行可能命令は全て検証可能な形で安全でなければならないが、信頼できるベースと呼ばれている新しいカーネル及びランタイムシステムの一部は、検証可能な形で安全ではない。言語の安全性がこの信頼できるベースを信頼できない実行可能命令から守っている。更に、ＳＩＰ各々の保全性は、命令の安全性、及びプロセスは他のプロセスのオブジェクト空間への参照を持たないというシステム全体に渡る不変条件に依存している。

［プロセス間通信］
記述した実装の少なくとも１つでは、ＳＩＰはチャネル上にメッセージを送信することにより排他的に通信を行う。チャネルは２つのプロセス間の双方向行動型の接続である。メッセージは、送信プロセスから受信プロセスに転送される交換ヒープ（ＥｘｃｈａｎｇｅＨｅａｐ）中の数値又はメッセージブロックのタグが付いた集合である。チャネルに沿ってメッセージ及び有効なメッセージのシーケンスのフォーマットを特定する規約によって、チャネルは型付けされる。

エキスポータ及びインポータとして非対称に型付けされた、出力パラメータ中のチャネルの２つのエンドポイントを返す、規約の静的な新規チャネル（ＮｅｗＣｈａｎｎｅｌ）方法を呼び出すことにより、ＳＩＰはチャネルを生成する。

ＳＩＰは既存のチャネルを介して他のプロセスにエンドポイントの一方又は両方を渡すことができる。エンドポイントを受信するプロセスは、エンドポイントに対応する他端を保持するプロセスへのチャネルを有する。例えば、もしあるアプリケーションプロセスがあるシステムサービスと通信を行いたければ、アプリケーションは２つのエンドポイントを生成し、１つのエンドポイントを含むリクエストをそのシステムの名前サーバに送信する。名前サーバはエンドポイントをそのサービスに転送するが、その際プロセスとサービスとの間のチャネルを確立する。

チャネル上の送信は非同期である。受信は特定のメッセージが到着するまでは同期的にブロックする。言語の特徴を使用すれば、スレッドは、チャネルに沿ってメッセージのセットの最初を待つことができるし、又は異なったチャネルからのメッセージの特定のセットを待つこともできる。データがチャネルを介して送信される際に、所有権はメッセージへの参照を保持していないかもしれない送信プロセスから、受信プロセスに移る。この所有権の不変条件は言語及びランタイムシステムにより実施され、３つの目的に役立つ。１番目は、プロセス間での共用を防ぐことである。２番目は、メッセージのポインタエイリアシングを除去することにより、静的なプログラムの解析を容易にすることである。３番目は、コピー又はポインタパッシングにより実装可能なメッセージパッシングセマンティックスを提供することにより実装の柔軟性を可能にすることである。

［分離された拡張性］
ソフトウェアの作成者は、彼らのシステムのユーザ又はアプリケーションのユーザに要求される完全な機能性を予想するのは稀である。モノリシックなシステムで誰でも満足させようとするよりはむしろ、重要なソフトウェアは大抵追加の実行可能命令をロードすることによりその機能性を強化する機構を提供する。例えば、従来の市販のパーソナルコンピュータのオペレーティングシステムは１００，０００を超える第三者のデバイスドライバをサポートしており、それによってＯＳはどのようなハードウェア装置でも大抵制御することができる。同様にして、無数のインターネットブラウザのアドオン及びエクステンションは、ウェブページのためのブラウザインタフェース及びコンポーネントを強化する。エクステンションは新たなソフトウェアバージョンよりも開発及び分散しやすいので、潜在的に変更される可能性はあるが、オープンソースプロジェクトでさえ「プラグイン」機構を提供している。

エクステンションは普通、エクステンションの親のアドレス空間に動的にロードされる実行可能命令からなる。親の内部インタフェース及びデータ構造に直接アクセスすることにより、エクステンションは充実した機能性を提供することができる。しかしながら、この柔軟性には高いコストがかかる。エクステンションは、ソフトウェアの信頼性、セキュリティ、下位互換性の問題の主要な要因になる。エクステンションの実行可能命令は、信頼できず、検証されておらず、間違っていて、又は悪意のあることもしばしばあるが、ハードインタフェース、境界、ホストとエクステンションとの間の区別なしにプログラムのアドレス空間に直接ロードされる。

エクステンションは非互換性、低機能性、又は他のエラーの原因になることがしばしばある。更に、エクステンションにはハードインタフェースが無いので、その親の実装に詳細を依存することになるため、プログラムの将来のバージョンへの展開を制約し、非互換性を避けるために広範囲にわたるテストの実施が必要になる。

実行可能命令を動的にロードすると、もうひとつの、明白ではないが無理な負担が性能及び正確さにかかる。実行可能命令を動的にロードできるシステムは、システムの状態、不変条件、又は有効な遷移について適切な想定を行うことが困難又は不可能なオープン環境である。割り込み、例外、又はスレッドスイッチが、新しいファイルをロードし、クラス及びメソッドボディを無効にして、全体状態を修正する命令をいつでも実行することができるＪａｖａ（登録商標）仮想マシン（ＪＶＭ）を考えよう。一般には、２つの実行可能命令間で環境が任意に変えることができないという不健全な想定に基づく場合を除けば、そのような環境内で実行しているプログラムを解析する実現可能な方法は存在しない。

本明細書に記述した１又は複数の実装で用いられている新しいアプローチでは、実行可能命令の動的なローディングを禁止し、動的に生成されたエクステンションをそれ自身の環境で分離する。これらの方針にそった試みが以前広く使用されなかったのは、分離メカニズムには性能及びプログラミングの問題があり、分離せずに実行するリスクよりも魅力をなくしているからである。

一番広く用いられている分離メカニズムは従来のＯＳプロセスであるが、コストが高いので有用性が限られている。最近のプロセッサに関するメモリ管理を行うハードウェアは、プロセスに厳しい境界を設けてプロセス状態を保護するが、プロセス間制御及びデータ転送に大きなペナルティを課している。最新のｘ８６プロセッサに関しては、プロセス間のスイッチングには数百から数千サイクルを要する可能性があるが、これにはＴＬＢ及びキャッシュのリフィルミスは含んでいない。

Ｊａｖａ（登録商標）仮想マシン（ＪＶＭ）及びＭｉｃｒｏｓｏｆｔ（登録商標）共通言語ランタイム（ＣＬＲ）等のさらに最近のシステムは、拡張性を持つように設計されているので、同じアドレス空間で実行しながら計算を分離するメカニズムとしてハードウェアではなくて言語の安全性を使用している。しかしながら、安全な言語は、それ自体が分離を十分に保証していない。データ共有すれば計算対象空間の間にパスが提供されるが、その時点でリフレクションＡＰＩはデータ抽象化及び情報隠蔽を弱体化させるメカニズムを提供する。その結果、これらのシステムには、システム機構やインタフェースへのアクセスを制御するためのＪＶＭ細粒アクセス制御又はＣＬＲのコードアクセスセキュリティ等の、複雑なセキュリティ機構とポリシーが必要である。

さらに、ランタイムシステムを共有して同じプロセスで実行する計算は、失敗しても分離されない。ＪＶＭ内で実行中の計算が失敗すると、破壊されたデータを分離、廃棄して、失敗した計算を再スタートするクリーンポイントを見つけることが困難なので、一般にＪＶＭプロセス全体を再スタートする。

本明細書に記述した少なくとも１つの実装では、閉じた環境内でシステムコンポーネントの実行可能命令をカプセル化するためにＳＩＰを利用する。システム又はアプリケーションへの拡張は、新しいＳＩＰ内で実行され、制限はされているが適切な機能性を提供しているチャネルを介して親と通信している。もし拡張に失敗すると、そのＳＩＰが終了して、ＯＳがリソースを再要求して通信相手に通告できるようになる。これらの相手はエクステンションとは状態を共有していないので、エラー訂正は局所的に行われチャネルの明示的プロトコルにより容易になる。

本明細書に記述した１又は複数の実装では、コンパイル時リフレクション（ＣＴＲ）を提供しており、それはファイルがコンパイルされて新しい実行可能命令を生成する際に実行する機能性を提供している。実行時に実行する通常のリフレクションは、ランタイム値にアクセスし、ＣＴＲよりもより一般的である。しかしながら多くの場合は、望ましい新しい実行可能命令は実行前には分かっているものである。その場合は、ＣＴＲは新しい実行可能命令をコンパイル中に作成する。

［分離されたデバイスドライバの構成をサポートするコンピュータアーキテクチャ］
ドライバの実行可能命令をカーネルの実行可能命令から分離するメカニズムがない状態で、カーネルのアドレス空間及びハードウェア保護ドメインにロードされている従来のデバイスドライバもある。しかしながら、記述した実装の１又は複数は、分離されたデバイスドライバをサポートするオペレーティングシステムについて記述している。

図２は、分離されたエクステンション及びデバイスドライバの構成、及び本明細書に記述した１又は複数の実装をサポートする、例示的なオペレーティングシステム（ＯＳ）アーキテクチャ２００を示す。描かれているように、例示的なＯＳアーキテクチャ２００は、カーネル２１０、１又は複数のデバイスドライバ２２０、１又は複数のファイルシステム２３０、及び１又は複数のアプリケーション２４０を示す。当業者であれば、ＯＳはファイルシステム３３０等ＳＩＰ内で実行する追加のＯＳサービスを含むことができることを認識するであろう。

カーネル２１０は特権を有するシステムコンポーネントであり、ハードウェアリソースへのアクセスを制御し、メモリを割り当てて再要求を行い、スレッドを生成してスケジューリングを行い、プロセス内のスレッドの同期を提供し、Ｉ／Ｏ管理を行う。

カーネル２１０はＯＳの中核機能性を提供する。例えば、メモリ又は他のハードウェアリソースの管理、プロセスの生成及び終了、プロセス間通信、チャネル操作、スケジューリング、及びＩ／Ｏ等が含まれる。このカーネル２１０のコンポーネントのいくつかは、ＩＯマネジャ２１１、スケジューラ２１２、ページマネジャ２１３、デバイスドライバコーディネータ２１４、及びハードウェア抽象化層（ＨＡＬ）２１５を含む。

この例示的なＯＳアーキテクチャ２００内の実行可能命令は、検証又は信頼されたものである。検証された命令の型の安全性及びメモリの安全性はコンパイラによりチェックされている。検証ができない命令は、ＯＳにより信頼されなければならず、ＨＡＬ２１５、カーネル２１０、及び信頼できるランタイム３２４、３３４、３４４の部分に限定されている。カーネルは大抵検証可能な程度に安全である。

カーネルの外にある実行可能命令及び信頼できるランタイムは全て、Ｃ＃またはＪａｖａ（登録商標）等の安全な言語で書かれており、Ｍｉｃｒｏｓｏｆｔ（登録商標）中間言語（ＭＳＩＬ）等の安全な中間言語に翻訳され、他の１又は複数のバックエンドコンパイラによりプロセッサ実行可能命令にコンパイルされる。

カーネルの命令とＳＩＰの命令との間の境界線は、信頼できるランタイムシステムにより不明瞭になっている。信頼できるランタイムは、信頼されているが検証することができない実行可能命令を含む。検証された型の安全性が、安全なインタフェースを介する場合以外はランタイムシステム及びそのデータ構造と相互作用するのを防ぐので、ランタイムの実行可能命令はＳＩＰの命令から保護されている。多くの場合、バックエンドコンパイラは、命令を信頼できるランタイムからＳＩＰの他の実行可能命令の中に安全に埋め込むことが可能であり、その際従来カーネルの中で実行していた操作をユーザプロセスへ安全に移動させる。

デバイスドライバ２２０の実行可能命令は、デバイスドライバのプログラマにより書かれた命令、さらに１又は複数のクラスライブラリ２２２及びその信頼できるランタイム２２４からの実行可能命令を含む。同様に、図に示すように、ファイルシステム２３０はクラスライブラリ２３２及びその信頼できるランタイム２３４からの実行可能命令を含む。更に、図に示すように、アプリケーション２４０はクラスライブラリ２４２及びその信頼できるランタイム２４４からの実行可能命令を含む。

図３は、例示的なデバイスドライバプロセス３００内の構成に関連したオブジェクト、及び本明細書に記述した１又は複数の実装によりサポートされている例示的なオペレーティングシステム（ＯＳ）アーキテクチャ２００の他の部分との関係を示している。図に示すように、例示的なＯＳアーキテクチャ２００はＯＳカーネル２１０、例示的なデバイスドライバプロセス３００、ハードウェア及び他のコンピューティングリソース３５０を示す。

ＯＳカーネル３１０は、１又は複数のチャネル３１２を含み、プロセス間のメッセージパッシングを可能にする。図に示すように、ハードウェア及び他のコンピューティングリソース３５０は、Ｉ／Ｏポート３５２（Ｉ／Ｏレジスタとしても知られている）、Ｉ／Ｏメモリ３５４、ＤＭＡコントローラ３５６、及び割り込み要求（ＩＲＱ）ライン３５８を含む。勿論、これらはあるハードウェア及び他のコンピューティングリソースの例にすぎない。実装が異なれば、共通の又は共通でない他のハードウェア及び他のコンピューティングリソース含んでもよい。実装はまた、１つより多くのＩ／Ｏポート３５２、Ｉ／Ｏメモリ３５４、ＤＭＡコントローラ３５６、または割り込み要求ライン３５８を含んでもよい。これらの型のハードウェアリソース全ては含まない実装もある。

例示的なデバイスドライバプロセス３００は、デバイスドライバの機能を実装しているオブジェクト、すなわちデバイスドライバオブジェクト３２６を含む。デバイスドライバプロセス３００はまた、信頼できるランタイム２２４、ゼロ以上のクラスライブラリ２２２、及び構成オブジェクト３２８を含む。

デバイスドライバオブジェクト３２６は、信頼できるプログラムモジュールの一例を含む。従来のアプローチとは異なり、デバイスドライバの実行可能なコードは自由に支配できない。しかしながら、そのアクションはいずれも監督されたりチェックされたりすることはない。その代わり、本明細書に記述した１又は複数の実装では、信頼できないデバイスドライバは、限定されたコンピューティングリソースのセットへ自由だが間接的なアクセスを与えられている。

信頼できるランタイム２２４は、ハードウェア及びＩＰＣリソースへのアクセスを仲介するアクセスオブジェクトを含む。このアクセスオブジェクトは、（一例としてであり、限定するものではないが）Ｉｏポート３３２、Ｉｏメモリ３３４、ＩｏＤｍａ３３６、ＩｏＩｒｑ３３８、及びエンドポイント３４０を含む。信頼できるランタイム２２４のアクセスオブジェクトは、以下のリソースのためのゲートウェイとして動作する。
ｏポート３３２ → Ｉ／Ｏポート３５２；
Ｉｏメモリ３３４ → メモリ３５４；
ＩｏＤｍａ３３６ → ＤＭＡチャネル３５６；
ＩｏＩｒｑ３３８ → ＩＲＱライン３５８；
エンドポイント３４０ → チャネルハンドラ３１２

従来のデバイスドライバとは異なり、デバイスドライバオブジェクト３２６の実行可能命令を含むファイルは、デバイスドライバを構成したり、または３５０で図示したようなハードウェア及び他のコンピューティングリソースに直接的にアクセスするための実行可能命令を含まない。その代わり、デバイスドライバオブジェクト３２６内の実行可能命令は、実行可能命令が信頼できるランタイム２２４内に含まれているアクセスオブジェクト３３２、３３４、３３６、３３８、及び３４０を介して、ハードウェア及び他のコンピューティングリソースにアクセスするだけである。

構成オブジェクト３２８を生成してアクセスオブジェクト３３２、３３４、３３６、３３８、及び３４０にアクセスする実行可能命令は、デバイスドライバのプログラマにより提供されるファイルには含まれない。その代わり、デバイスドライバのプログラマは、デバイスドライバのための実行可能命令に付属するメタデータとして構成要件を埋め込む。既述の１又は複数の実装では、構成オブジェクト３２８、及びアクセスオブジェクト３３２、３３４、３３６、３３８、及び３４０を生成する実行可能命令は分離されており、デバイスドライバオブジェクトの残りの実行可能命令とは区別される。

１又は複数の実装では、構成オブジェクト３２８を生成する実行可能命令は、オペレーティングシステムにより提供される。実装の１つでは、これらの実行可能命令は、インストール時にコンパイル時リフレクション（ＣＴＲ）テンプレートを使用して生成される。ＣＴＲテンプレートは、デバイスドライバ内で符号化された構成オブジェクトの記述内のメタデータとして埋め込まれている構成要件を処理する。別の実装では、デバイスドライバオブジェクト３２６のための実行可能命令を含むファイル内で構成メタデータからその一部が生成されたマニフェストをＣＴＲテンプレートは処理する。別の実装では、信頼できるランタイム２２４内の実行可能命令は、構成メタデータかデバイスドライバマニフェストかどちらかを解釈することにより、構成オブジェクトを生成する。

例示的なＯＳアーキテクチャ２００は、別個のソフトウェア分離プロセス（ＳＩＰ）で各デバイスドライバ（ドライバ２２０等）を実行する。例示的なＯＳアーキテクチャ２００は、言語の安全性を使用してＳＩＰが別のＳＩＰのページに書き込むことができないということを検証する。ＳＩＰ内にカプセル化されているので、オペレーティングシステム全体を停止しなくても、個々のドライバは必要に応じて止めたり再起動したりすることができる。

例示的なＯＳアーキテクチャ２００のためのプログラムは、インストール時に信頼できるランタイムに静的にリンクされる。プログラムは型の安全性のために静的に検証されているが、信頼できるランタイムは各々システムの信頼できるコンピューティングベース（ＴＣＢ）の要素になっている。信頼できるランタイム内からの実行可能命令は、プロセス分離を維持して、他のプロセスのメモリ及びハードウェアリソースに影響を与えずに、ホストプロセッサの特権／監督モードでプロセスを実行できる。前述のある１つの実装では、型の安全性を回避可能な動的なリフレクション又は他のメカニズムは、デバイスドライバプログラマにより提供された実行可能命令の中では許可されていない。

デバイスドライバのための信頼できるランタイムは、ハードウェアとの通信を抽象化する安全な環境を提供する。割り込み要求を処理したり、固定メモリにアクセスしたり、Ｉ／Ｏポート（ＩＯレジスタとしても知られている）にアクセスしたり、ダイレクトメモリアクセスコントローラ（ＤＭＡ）を制御するプロセッサの実行可能命令は、ドライバランタイムにより公表されているアクセスオブジェクトを介して保護されている。

プロセス間通信（ＩＰＣ）は全て、強力に型付けされた双方向チャネルを介している。これらのチャネルは、正確に２つのエンドポイントを有する。チャネルに関するメッセージは値型に制限されており、これらのメッセージのフォーマットは規約により定義されている。この規約は、チャネル全域で送信されるメッセージの有効なシーケンスを特定するチャネルプロトコルの役目もするもので、通信を開始するためのハンドシェークステップを含んでいる。アプリケーションが規約に適合するかを静的に検証することができる。

クライアントが接続しやすくするために、公開名を持つエンドポイントもある。これは、個々の起源でグローバルにアクセス可能な名前空間を介して実現される。グローバルな名前空間サーバが名前空間を管理して、名前からチャネルのエンドポイント、ディレクトリ、及びシンボリックリンクにマッピングできるようにしている。名前空間は、永続性のあるバッキングストアには付属していない。その代わり、システムポリシーによりアプリケーションの一部（ファイルシステム等）が、名前空間内に仮想サブツリーを生成して、そのツリー内にコンテントをマッピングすることが許可されている。このため、ファイルアクセスはチャネルの抽象化を介しているという識別で従来のファイルシステムと同等のものになっている。

例示的なＯＳアーキテクチャ２００は、アプリケーション（２４０等）を第１のクラスのエンティティとして取り扱うための抽象概念を備えており、それによりオペレーティングシステムがアプリケーションについて推論したり保証を与えたりすることが可能になる。デバイスドライバはこの抽象化のサブクラスである。更に、デバイスドライバのインストールは、アプリケーション上でＯＳによって行われる第１のクラスの操作である。

例示的なＯＳアーキテクチャ２００では、デバイスドライバはそのＩ／Ｏ及びＩＰＣ構成要件を宣言する。従来のアプローチでは、構成要件を発見することができない。ここでは、構成要件はデバイスドライバの実行可能命令と同じファイル内で符号化される。符号化された構成要件は処理を簡単にするために、構成要件を宣言するスタンドアローンの仕様に変換することができる。

構成要件は、コンパイル時、インストール時、ブート時、実行時に検証することができる。要するに、構成要件をデバイスドライバと同じファイルに符号化すると、自己記述アーチファクトに変えてしまう。デバイスドライバのためのＭＳＩＬアセンブリのセットが与えられれば、デバイスドライバが正しく機能するために満足しなければならない構成の前提条件（及び、ソフトウェア及びハードウェアリソース双方への依存性）についてＯＳは完全に判断することができる。

アプリケーション抽象化及びドライバ構成宣言では、例示的なＯＳアーキテクチャ２００は、デバイスドライバにより使用されるＩ／Ｏ及びＩＰＣリソースについて保証することができる。例えば、新しいデバイスドライバが所望するリソースのセットを、他の全てのデバイスドライバが使用しているリソースのセットと比較し、Ｉ／Ｏポート又はＩ／Ｏメモリの範囲等のリソースが重複、及び従って競合していないかをチェックすることにより、ドライバが実行する前にＯＳが構成の競合を検出することができる。好適な実施形態においては、構成の競合はインストール時に検出され、新しいデバイスドライバと過去にインストールされた全てのデバイスドライバを含む残りのシステムとの間で競合が無い場合のみにインストールは許可される。

もう１つの例として、各デバイスドライバからその構成の依存性を抽出して、その依存性の１つより以前に初期化されるデバイスドライバがないようにリストを分類することにより、ＯＳは有効な全体のブート順序、すなわちデバイスドライバが初期化される順序、を生成することができる。ブート順序を開発時にＯＳ中にハードコード化するか、管理者が手作業でブート順序を更新する以前のシステムに対して、有効なシステム全体のブート順序を自動的に生成することは著しい進歩である。宣言構成要件から得られる保証の最後の例として、ドライバの構成及びリソースの獲得に関連するドライバを初期化するための実行可能命令全てを、ＯＳが生成することができる。そのため、ドライバは宣言されたリソースを使用するだけであり、そのリソースはシステムのポリシーに従って獲得されるということをＯＳは保証することができる。このような能力により、ランタイム性能において大きなコストをかけずにシステムの信頼性や保全性を向上させることができる。

［デバイスドライバ調整］
従来のアプローチとは異なり、本明細書に記述した１又は複数の実装のデバイスドライバコーディネータ２１４は、ドライバが不適切なメモリ位置又は他のハードウェアリソースにアクセスするのを防ぐ。逆に言えば、デバイスドライバコーディネータは、ドライバが適切なメモリ位置及び他のハードウェアリソースにのみアクセスするのを許可する。更に、ドライバがハードウェア及びリソースに直接アクセスすること（従来のアプローチが許可していること）よりむしろ、ドライバがハードウェア及びリソースにアクセスするのをカーネル２１０が点検している。

本明細書に記述した１又は複数の実装は、ＨＡＬ２１４、Ｉ／Ｏマネジャ２１１、ドライバ２２０という３層からなる入出力（Ｉ／Ｏ）システムを有する。ＨＡＬ２１４は小規模で、コンピュータのハードウェアへのアクセスを抽象化する信頼できる実行可能命令のベースである。例えば、ある実施形態では、ハードウェアを操作するのにＨＡＬは４つのアクセスオブジェクトを実装した。すなはち、ＩＯポート３５２（Ｉ／Ｏレジスタとしても知られている）にアクセスするＩｏポートオブジェクト３３２、Ｉ／Ｏメモリ３５４にアクセスするＩｏメモリオブジェクト３３４、ＤＭＡコントローラ３５６にアクセスするＩｏＤｍａオブジェクト３３６、及び割り込み要求ライン３５８にアクセスするＩｏＩｒｑオブジェクト３３８である。ある実施形態では、ＨＡＬ３１４はタイマ、割り込みコントローラ、リアルタイムクロックハードウェアを制御する実行可能命令を含む。Ｉ／Ｏマネジャ２１１は、デバイスドライバを初期化してデバイスドライバ２２０にアプリケーションを接続する責任がある。

カーネル２１０は、デバイスドライバ２２０の構成メタデータを直接使用するか、または各デバイスドライバのためのマニフェスト（例えば、図１で示したプロセスマニフェスト１４２）を使用して、デバイスドライバ２２０を構成してリソースを正しく実行するという要求を満たすように接続する。スタートアップに際して、カーネル２１０はシステムのプラグアンドプレイ構成を行う。カーネル２１０は、ＢＩＯＳからブートローダにより獲得した情報、及びＰＣＩバス等のバスから獲得した情報を使用して、デバイスを数え上げ、適切なデバイスドライバを起動して、デバイスハードウェアへのアクセスをカプセル化するこれらのドライバオブジェクトを引き渡す。

各ドライバ２２０は、安全な実行可能命令で記述されており、自分自身のプロセスの中で実行される。ドライバは、ネットワークスタック及びファイルシステムを含むシステムの他の部分と専らチャネルを介して通信を行なう。ドライバが起動すると、Ｉ／Ｏマネジャ２１１は、デバイスドライバ２２０のマニフェストにより必要とされているように、デバイスハードウェア３５２、３５４、３５６、及び３５８と通信するために、アクセスオブジェクト３３２、３３４、３３６、及び３３８を提供する。ハードウェアのメモリマッピングされた場所に直接アクセスする前に、これらのアクセスオブジェクトは全て、各参照をチェックする安全なインタフェースを提供する。

ソフトウェア分離を使用した実施形態の１つでは、Ｉ／Ｏアクセスオブジェクトのための実行可能命令全体が信頼できるランタイム３２４内に含まれていて、ドライバ−ドライバプロセス３００内で実行されている。ハードウェアへのアクセスが有効であることを保証するためのチェックは、実行可能命令により信頼できるランタイム２２４内のＩ／Ｏアクセスオブジェクト３３２、３３４、３３６、及び３３８内で実施される。ハードウェア分離を使用するもう１つの実施形態では、ドライバがアクセスを許可されたＩ／Ｏポート空間、またはＩ／Ｏメモリ空間の特定の領域だけにデバイスドライバがアクセスを許可されるように、プロセッサのプロセス分離ハードウェアがプログラムされている。ハードウェア分離を使用している実施形態では、プロセス分離ハードウェアを構成するための実行可能命令はＯＳカーネル２１０内にある。

［ドライバ構成］
１又は複数の実装ではシステムコンポーネント内でメタデータで符号化された構成要件を使用して、システムの要素を記述し、どのように組み合わせるのかを説明して、システムの他の部分との行動相互作用を特定している。カーネル、アプリケーション、又はデバイスドライバ、及びその構成要件等、システムの各コンポーネントにメタデータは宣言型でラベルを付ける。構成要件は、依存性、エクスポートサービス、及びリソース要求についての情報を含む。ツールによりこのメタデータを使用して、システムの実行前にシステムコンポーネントの実行可能命令が正しく構成されることができるか検証する。このメタデータは、システム実行中にシステムの各コンポーネントを正しく構成するのに使用されるので、プログラマの意図しているように実行することができる。

システムメタデータはマニフェストと呼ばれる１又は複数のシステムストアにアーカイブされる。トップレベルのシステムのマニフェストは、個々のコンポーネント（デバイスドライバ等）を記述するマニフェストのことを示す。これらのマニフェストを介して、ブートローダ又はシステムベリファイア等のソフトウェアは、システムのあらゆるコンポーネントを発見することができる。

システムマニフェストは、システムのオフライン解析を有効にするのには十分である。本明細書に記述した実装では、ハードウェアデバイス及びシステムマニフェストの記述のみを使用して、管理者は「デバイスドライバ」に関連した質問への回答の多くを発見することができる。そのような質問には、例えば、システムは特定のハードウェア上でブートするか、どのドライバ及びサービスが初期化するか、どのアプリケーションが実行可能か等、が含まれる。

［仕様］
実行可能なシステムイメージは、メタデータとして埋め込まれたシステム全体に対する構成要件を含んでいる。メタデータを使用して、記述した実装の１又は複数では３つの不変条件を維持している。第１に、別のドライバ又はシステムの別の部分と競合する構成要件のために、うまく起動できないデバイスドライバをＯＳはインストールしない。第２に、構成の競合又はリソース欠如のどちらかのためにうまく実行できないようなデバイスドライバをＯＳは起動しない。第３に、デバイスドライバは構成要件の中で宣言されていないリソースを実行時に使用することはできない。

可能であれば、本明細書に記述した１又は複数の実装は、高レベル言語でカスタムメタデータ属性を使用して、構成要件をソースコードにインタリーブするので、ソースドキュメントを１つだけ維持しなければならない。カスタム属性は、クラス、メソッド、又はフィールド宣言等のソースコードエンティティに添付することができる。コンパイラは属性を、結果として生じる中間言語の実行可能命令を含むファイルに符号化する。命令を実行しなくても、コンパイラ、リンカ、インストールツール、検証ツールは実行可能命令で符号化されたメタデータを読み取ることができる。

一例として以下のソースコードは、ビデオデバイスドライバ（Ｓ３（商標）Ｔｒｉｏ６４（商標）ビデオデバイスドライバ等）の構成要件を宣言するために使用するいくつかの属性を示す。
[Signature(”/pci/03/00/5333/8811”)]
class S3Trioconfig : DrivercategoryDeclaration
{
// Hardware resources from PCI config
[IoMemoryRange(0, Default = Oxf8000000, Length = 0x400000)]
IoMemoryRange frameBuffer;

// Fixed hardware resources
[IoFixedMemoryRange(Base = OxbδOOO, Length = 0x8000)]
IoMemoryRange textBuffer;

[IoFixedMemoryRange(Base = 0xa0000, Length = 0x8000)]
IoMemoryRange fontBuffer;

[IoFixedPortRange(Base = OxO3cO, Length = 0x20)]
IoPortRange control ;

[IoFixedPortRange(Base = 0x4ae8, Length = 0x02)]
IoPortRange advanced;

[IoFixedPortRange(Base = 0x9ae8, Length = 0x02)]
IoPortRange gpstat;

// channels
[ExtensionEndpoint(typeof(ExtensionContract.Exp))]
TRef<Extensioncontract. Exp:start> iosys;

[ServiceEndpoint(typeof(VideoDeviceContract. Exp))]
TRef<ServiceProvidercontract. Exp:start> video;
・・・
}

［ＤｒｉｖｅｒＣａｔｅｇｏｒｙ］及び［Ｓｉｇｎａｔｕｒｅ］属性は、このモジュールがＰＣＩビデオ装置の特定クラスのためのデバイスドライバであることを宣言している。ＤｒｉｖｅｒＣａｔｅｇｏｒｙは、特定のハードウェアのためのデバイスドライバを実装するアプリケーションのカテゴリを示す。他のカテゴリはソフトウェアサービスを実装するアプリケーションのためのＳｅｒｖｉｃｅＣａｔｅｇｏｒｙ、及びウェブサーバへ拡張するためのＷｅｂＡｐｐＣａｔｅｇｏｒｙを含む。

［ＩｏＭｅｍｏｒｙＲａｎｇｅ］属性は、ｆｒａｍｅＢｕｆｆｅｒがデバイスのＰＣＩ構成空間の中で得られた最初のエントリであることを宣言する。ハードウェアが構成され、メモリ領域の大きさ等のハードウェアパラメータが、属性内の構成値と互換性がなければならない場合、このフレームバッファの位置が判定される。メモリマップドアクセスのためのアドレス空間の固定領域か、又はデバイスレジスタにアクセスするＩ／Ｏポートの固定領域のどちらかがドライバに必要であることを［ＩｏＦｉｘｅｄＭｅｍｏｒｙＲａｎｇｅ］と［ＩｏＦｉｘｅｄＰｏｒｔＲａｎｇｅ］属性は明示している。

この実施形態では、ＩｏＤｍａＲａｎｇｅ、ＩｏＩｒｑＲａｎｇｅ、ＩｏＭｅｍｏｒｙＲａｎｇｅ、ＩｏＰｏｒｔＲａｎｇｅオブジェクトは連続したアクセスオブジェクトを集めるための入れ物であり、ＩｏＤｍａ、ＩｏＩｒｑ、ＩｏＭｅｍｏｒｙ、ＩｏＰｏｒｔアクセスオブジェクトとそれぞれ交互に使用できる。

［ＥｘｔｅｎｓｉｏｎＥｎｄｐｏｉｎｔ］属性は、ドライバの親プロセスと通信するために、ドライバはチャネルのエンドポイントと共に構成されなければならないことを宣言している。Ｓ３（商標）Ｔｒｉｏ６４（商標）等のデバイスドライバの場合は、Ｉ／Ｏシステムが親プロセスである。

［ＳｅｒｖｉｃｅＥｎｄｐｏｉｎｔ］属性は、システムディレクトリサービスに対してドライバはチャネルのエンドポイントと共に構成されなければならないこと、及びビデオドライバを使用しているアプリケーションはこのエンドポイントを介してディレクトリサービスによりデバイスドライバに拘束されることを宣言する。

［コンパイル時］
コンパイル時には、高レベル言語のコンパイラは、カスタム属性をメタデータとして、デバイスドライバのための中間言語の実行可能命令を含むファイルに埋め込む。記述した実装の１又は複数は、中間言語メタデータアクセスライブラリを使用して、ファイル内に含まれる実行可能命令を実行することなく、埋め込まれたメタデータを中間言語ファイルから取り出すことができる。

リンク時には、マニフェスト生成ツールは中間言語ファイルからカスタム属性メタデータを読み取ってアプリケーションマニフェストを生成する。アプリケーションマニフェストは、アプリケーションのコンポーネント及び構成要件を数え上げるＸＭＬファイルである。アプリケーションマニフェストについては「自己記述アーチファクト及びアプリケーションの抽象化」でさらに詳細に記述している。

以下のＸＭＬはビデオデバイスドライバ（Ｓ３（商標）Ｔｒｉｏ６４（商標）ビデオデバイスドライバ等）のためのマニフェスト情報の一部を含む。
<manifest>
<app1ication identity=”s3Trio64” />
<assemblies>
<assembly filename=”s3Trio64.exe” />
<assembly fi1ename=”Namespace.Contracts.dll ” version=”l.0.0.2299” />
<assemb1y filename=”lo.Contracts.dll ” version=”l.0.0.2299” />
<assembly filename=”Corlib.dll ” version=”l.0.0.2299” />
<assemb1y filename=”Corlibsg.dll ” version=”l.0.0.2299” />
<assembly fi1ename=”System.compi1er.Runtime.dll ” version=”l.0.0.2299” />
<assemb1y fi1ename=”MS.Singsharp.Runtime.dl1 ” version=”l.0.0.2299” />
<assemb1y filename=”ILHelpers.dll” version=”l.0.0.2299” />
<assemb1y filename=”OS.Vl.ill” version=”l.0.0.2299” />
</assemblies>
<drivercategory>
<device signature=”/pci/03/00/5333/8811” />
<ioMemoryRange index=”0” baseAddress=”Oxf8000000” rangeLength=”0x400000” />
<ioMemoryRange baseAddress=”Oxb8000” rangeLength=”0x8000” fixed=”True” />
<ioMemoryRange baseAddress=”0xa0000” rangeLength=”0x8000” fixed=”True” />
<ioPortRange baseAddress=”0x3c0” rangeLength=”0x20” fixed=”True” />
<ioPortRange baseAddress=”0x4ae8” rangeLength=”0x2” fixed=”True” />
<ioPortRange baseAddress=”0x9ae8” rangeLength=”0x2” fixed=”True” />
<extension startstateld=”3” contractName=”MS.OS.Extending-
.ExtensionContract” endpointEnd=”Exp” assembly=”Namespace.contracts” />
<serviceProvider startstateld=”3” contractName=” MS.OS.lo-
.VideoDeviceContract” endpointEnd=”Exp” assembly=”lo.Contracts” />
</driverCategory>
・・・
</manifest>

［インストール時］
本明細書に記述した１又は複数の実装では、起動できないデバイスドライバをインストールしないことをシステムは保証している。そのために、デバイスドライバがインストールされる前に、デバイスドライバの構成要件全体を満足できることをシステムが検証する。

アプリケーションは、本明細書に記述した１又は複数の実装をサポートするＯＳ内の第１のクラスの抽象化である。このコンセプトについては「自己記述アーチファクト及びアプリケーションの抽象化」でさらに詳細に記述している。ある実施形態では、実行するために実行可能命令のセットがインストーラによりアプリケーションに追加されて、構成要件に従ってアプリケーションを初期化する。代替的実装では、構成要件に従ってアプリケーションを初期化する実行可能命令は、信頼できるランタイム中に含まれ、アプリケーションの構成メタデータを解釈することにより構成オブジェクト及びアクセスオブジェクトを生成する。

アプリケーションのマニフェストの中にメタデータがあるとインストーラが起動する。インストーラは、アプリケーションのアセンブリの各々が存在していて型及びメモリが安全であることを検証する。又、チャネル規約全てが正しく実装されていることも検証する。

これらの内部特性を解明し検証すると、インストーラは次に外部依存性の全てを解明し検証しようと試みる。例えば、デバイスドライバに使用されるハードウェアリソースはどれでも、他のどのドライバに必要とされるハードウェアリソースとも競合することはないことを、インストーラは保証する。インストーラはまた、アプリケーションが使用するあらゆる型のチャネルの存在を検証する。アプリケーションがチャネルをエクスポートする場合、エクスポートされたチャネルが別のアプリケーションと競合しないことをインストーラは検証する。競合が発生する場合は、システムのマニフェスト内のポリシーがそれらを解明する。例えば、１つのデバイスドライバだけがビデオコンソールの規約を提供できることを、マニフェストが宣言することもある。ビデオドライバの追加インストールが許されないか、又はブート時には単一のビデオドライバだけが起動されることになる。

コンパイル時リフレクション（ＣＴＲ）を使用して、信頼できる実行可能命令を生成し、システムリソースのためのアプリケーション構成オブジェクト及びアクセスオブジェクトを初期化する。ある実施形態では、ＣＴＲテンプレートはインストール時に、アプリケーションマニフェストにより名づけられたアセンブリ中で、属性を持たされたプログラム要素の処理を実行する。

システムマニフェストメタデータを更新して、新しいアプリケーション又はデバイスドライバを組み込むことで、インストールプロセスは完了する。

少なくとも１つの実装では、インストールプロセス全体がオフラインで行われ、インストールが目に見えるようになるのは次にシステムがブートされたときだけである。あるいは、インストールプロセス全体は、オンライン及び／又は部分的にオンラインで実行することもできる。

［実行時］
実行時にはメタデータは、カーネル、デバイスドライバ、サービス、及びアプリケーションの初期化を駆動する。ブートローダはシステムのマニフェストの一部を読み取り、どのカーネル、デバイスドライバ、及びサービスをロードすべきかを判定する。このロード及び起動が実行される順序はどこにも特定されていない。その代わり、システムが特定の依存性からそれを推察している。

各アプリケーションが起動すると、カーネルはメタデータ依存性全てを検証及び解明して、カーネル中にプロセス構成記録を立ち上げる。ＣＴＲを使用したアプリケーションに放出された信頼できる実行可能命令は、構成記録を解析して、構成オブジェクト３２８を生成し、外部リソースにアクセスするアクセスオブジェクト３３２、３３４、３３６、３３８、３４０を生成する。コンパイル時リフレクション（ＣＴＲ）は、構成オブジェクト４２８のために実行可能命令を生成する。

Ｓ３（商標）Ｔｒｉｏ６４（商標）デバイスドライバの例に戻ると、カーネルはｆｒａｍｅＢｕｆｆｅｒ、ｔｅｘｔＢｕｆｆｅｒ、ｆｏｎｔＢｕｆｆｅｒのためのＩｏＭｅｍｏｒｙＲａｎｇｅオブジェクトに対する要求をドライバの構成記録の中に記録する。カーネルはまた、制御、アドバンスト、ｇｐｓｔａｔＩ／ＯポートのためのＩｏＰｏｒｔＲａｎｇｅオブジェクトを記録している。カーネルはチャネルを生成してデバイスドライバをＩ／Ｏサブシステムに接続し、第２のチャネルはドライバを名前空間に接続する。チャネルのエンドポイントはドライバの構成記録に追加される。

デバイスドライバが実行を開始すると、信頼できるランタイム中の実行可能命令はドライバのオブジェクト空間内に適当なＩｏＭｅｍｏｒｙＲａｎｇｅ及びＩｏＰｏｒｔＲａｎｇｅのアクセスオブジェクトを生成する。これらを構築できるのは信頼できるランタイムだけであるので、デバイスドライバは構成メタデータの中で宣言され、カーネルＩ／Ｏサブシステムにより競合がないかチェックを受けたＩ／Ｏリソースにアクセスすることだけができる。

構成メタデータの中でチャネルのエンドポイントを宣言すると３つの特性が保証される。第１に、ＳＩＰのための実行可能命令を、チャネルの規約に厳密に適合して、完全に宣言したチャネルを介してのみ通信することを保証するよう静的に検証することができる。第２に、アプリケーションはグローバル名を含む必要はない。例えば、Ｓ３（商標）Ｔｒｉｏ６４（商標）ビデオデバイスドライバはシステム名前空間内の／ｄｅｖ／ｖｉｄｅｏ名を意識していない。その代わりドライバはローカル名Ｓ３Ｔｒｉｏ６４Ｃｏｎｆｉｇ．ｖｉｄｅｏを使用して所与の規約（ＳｅｒｖｉｃｅＰｒｏｖｉｄｅｒＣｏｎｔｒａｃｔ）でチャネルを参照する。Ｉ／Ｏ名前空間のレイアウト全体は、ビデオドライバ内ソースコードの一本のラインにも影響せずに変更することができる。第３に、最も可能性の低い特権の原則に適合して、アプリケーションは「サンドボックス」になることができて、現在のシステムにおけるエラーの原因及びセキュリティの脆弱性を取り除く。例えば、Ｓ３（商標）Ｔｒｉｏ６４（商標）ドライバは、システムのディレクトリサービスに接続されたエンドポイントを保持するが、新しい名前を生成したり、または他のシステムプロセスのどれにでも接続できる能力はドライバにはない。

［分離されたデバイスドライバの方法論的実装］
図４はどのようなエクステンション（デバイスドライバ等）でも初期化する方法４００を示す。この方法４００では、ＯＳがデバイスドライバのマニフェストからメタデータを読み取ってデバイスドライバオブジェクトを生成する。図１に描かれた１又は複数の様々なコンポーネントによりこの方法４００を行う。更に、方法４００は、ソフトウェア、ハードウェア、ファームウェア、またはその組み合わせで行うことができる。

図４の４０２において、オペレーティングシステム（ＯＳ）は信頼できないプログラムモジュール（デバイスドライバ等）を獲得する。ＯＳは、デバイスドライバのマニフェストから、必要な、または要求のコンピューティングリソースのセットを判定する。ここで、コンピューティングリソースは、仮想リソース（チャネル等）、又はハードウェアリソース（Ｉ／Ｏポート又はＩＯメモリの範囲等）、又は他のそのようなリソースを含むことができる。

ＯＳはデバイスドライバのマニフェストを読み取ることにより、この判定を行うことができる。あるいは、ＯＳはデバイスドライバの実行可能命令を分析することができる。あるいはまた、ＯＳは実行可能命令、又は関連したデータ構造からメタデータを抽出することもできる。

４０４において、リソースのいずれかがＯＳ又は他のデバイスドライバに既に割当てられているかどうかをＯＳは判定する。もし割当てられていれば、４０６でプロセスを中止する。本発明の代替的実施形態は、リソースが解放されていたら初期化プロセスを再起動する、リソースを解放するように現在のオーナーと協議する、ユーザに依頼して競合しているドライバを止める許可をもらう、デバイスドライバのライタに誤ったリソース要求がある可能性があることを通知する等、といった追加のポリシーをもって中止に従うことがある。

またここで、デバイスドライバ及び要求されたコンピューティングリソースに関連した他の判定をＯＳが行うことがある。デバイスドライバが要求コンピューティングリソースにアクセスすることを許可され、要求された通りにアクセスしていることをＯＳが確認する。

４０８において、ＯＳはデバイスドライバに対するリソースの割り当てを記録する。

４１０において、必要又は要求されたリソース各々に対してデバイスドライバにより使用される信頼できるローカルアクセスオブジェクトをＯＳが提供する。信頼できるランタイムオブジェクト（図３に描かれた）はローカルアクセスオブジェクトの例である。

ＯＳがここで行う「提供」には、既に予めセットされ固定された実行可能命令（及びデータ）、これらはローカルアクセスオブジェクトだが、それらを単に使用することを含んでもよい。特定の要求と条件にカスタマイズされた新しい命令（恐らくテンプレートに基づいた）を生成することを含んでもよい。またはＯＳがその中間で何かするかもしれない。例えば、ＯＳは、ローカルアクセスオブジェクトである既存の実行可能命令を構成したり、または僅かに変更してもよい。

実際ＯＳは信頼できるローカルアクセスオブジェクトの実行可能命令（及びデータ）を信頼できないデバイスドライバに挿入又はリンクできるので、挿入又はリンクされたローカルアクセスオブジェクトを介してデバイスドライバはアクセスを得られる。

４１２において、必要なリソースに対するローカルアクセスオブジェクトのセットを使用してＯＳはデバイス構成オブジェクトを初期化する。構成オブジェクトは、マニフェストの中で定義された追加設定を含む。追加設定の例としては、分類エクステンションにユーザの好むデータ／時間フォーマットを示す設定がある。

４１４において、ＯＳはデバイスドライバの実行可能命令の実行を開始する。デバイスドライバを初期化する実行可能命令は、ＯＳまたはインストールシステムにより提供され、デバイスドライバのプログラマによって提供されるのではない。

４１６において、実行中のデバイスドライバは、ローカルアクセスオブジェクトを介して要求されたコンピューティングリソースにアクセスする。更に、実行中のデバイスドライバは、要求されたコンピューティングリソース（他は不可）にアクセスすることだけ可能であり、それはリンクされた又は挿入されたローカルアクセスオブジェクトを介してだけである。

［結び］
本明細書に記述した技術は、多くの方法で実装でき、その方法は、（これに限定しないが）プログラムモジュール、汎用及び特殊用途のコンピューティングシステム、ネットワークサーバ及び機器、専用エレクトロニクス及びハードウェア、ファームウェアを、１又は複数のコンピュータネットワークの一部、及び／又はその組み合わせとして含む。

上述の１又は複数の実装は、構造特徴及び／又は方法論的ステップに特化した言語で記述されているが、当然のことながら、本明細書に記述した特定の例示的な特徴またはステップなしに、他の実装を実施することも可能である。むしろ、特定の例示的な特徴及びステップは、１又は複数の実装の好適な形態として開示されている。例示的な実装の記述を明確にするため、周知の特徴を省略または簡略化している例もある。さらに、分かりやすくするために、ある方法ステップを別個のステップとして描写している場合もあるが、これらの別個に描写されたステップは性能においては必ずしも順序に依存しているとは解釈すべきではない。

本明細書に記述した１又は複数の実装をサポートするオペレーティングシステムアーキテクチャの動作シナリオを示す図である。本明細書に記述した１又は複数の実装をサポートするオペレーティングシステムアーキテクチャのブロック図である。デバイスドライバプロセス内のオブジェクト、及び図２に示すオペレーティングシステムアーキテクチャの他の部分との関係のブロック図である。本明細書に記述した別の方法論的な実装のフロー図である。

Claims

プロセッサにより実行される際に１つの方法を実施するプロセッサ実行可能命令を有する１又は複数のプロセッサ可読媒体であって、前記方法は、
デバイスドライバ（３００）を取得するステップであって、前記デバイスドライバ（３００）は実行可能命令のセットであるステップと、
前記デバイスドライバ（３００）の前記実行可能命令のセットを実行するために必要なコンピューティングリソース（３１２及び３５０）のセットを判定するステップと、
前記必要なコンピューティングリソース（３１２及び３５０）のセットにアクセスするために前記デバイスドライバ（３００）により使用される１又は複数のローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を提供するステップであって、前記１又は複数のローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）は実行可能命令を有するステップと、
前記デバイスドライバ（３００）の前記実行可能命令のセット及び前記１又は複数のローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の前記実行可能命令の実行を開始するステップと
を有することを特徴とするプロセッサ可読媒体。
前記判定動作は、前記デバイスドライバ（３００）に関連したプロセッサ可読マニフェスト（１４２）を取得するステップを含み、前記デバイスドライバマニフェスト（１４２）が前記デバイスドライバ（３００）の前記実行可能命令のセットを実行するために必要な前記コンピューティングリソース（３１２及び３５０）のセットを特定することを特徴とする請求項１に記載の１又は複数の媒体。
前記方法は、前記デバイスドライバ（３００）が前記必要なコンピューティングリソース（３１２及び３５０）のセットにアクセスすることを許可されていることを確認するステップをさらに有することを特徴とする請求項１に記載の１又は複数の媒体。
前記提供動作は、前記必要なコンピューティングリソース（３１２及び３５０）のセットにアクセスするために前記デバイスドライバ（３００）により使用される１又は複数のローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を生成するステップをさらに有し、前記ローカルアクセスオブジェクトはオペレーティングシステムにより提供されることを特徴とする請求項１に記載の１又は複数の媒体。
プロセッサにより実行される際に１つの方法を実施するプロセッサ実行可能命令を有する１又は複数のプロセッサ可読媒体であって、前記方法は、
実行可能命令のセットを有する信頼できないプログラムモジュール（３００）を取得するステップであって、前記信頼できないプログラムモジュール（３００）は１又は複数のコンピューティングリソース（３１２及び３５０）にアクセスするように構成されているステップと、
前記信頼できないプログラムモジュール（３００）の１又は複数のターゲットコンピューティングリソース（３１２及び３５０）を判定するステップであって、前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）は、前記信頼できないプログラムモジュール（３００）の前記実行可能命令のセットが実行される際に、前記信頼できないプログラムモジュール（３００）がアクセスすることを求めるコンピューティングリソース（３１２及び３５０）であるステップと、
１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を前記信頼できないプログラムモジュール（３００）に提供し、前記提供された１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を介して、前記信頼できないプログラムモジュールが前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）へのアクセスを得るステップと
を有することを特徴とするプロセッサ可読媒体。
前記信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の各々は１又は複数のコンピューティングリソース（３１２及び３５０）に関連付けられており、前記信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の各々は実行可能命令のセットを有することを特徴とする請求項５に記載の１又は複数の媒体。
前記信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の各々は１又は複数のコンピューティングリソースに関連付けられており、前記信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の各々は実行可能命令を有すること、及び前記提供するステップは、前記１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の実行可能命令を構成して、前記１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）の前記構成された実行可能命令を介して、前記信頼できないプログラムモジュール（３００）に、前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）へのアクセスを提供するステップを有することを特徴とする請求項５に記載の１又は複数の媒体。
前記信頼できないプログラムモジュール（３００）はデバイスドライバ（３００）であることを特徴とする請求項５に記載の１又は複数の媒体。
プロセッサにより実行される際に１つの方法を実施するプロセッサ実行可能命令を有する１又は複数のプロセッサ可読媒体であって、前記方法は、
実行可能命令のセットを有する信頼できないプログラムモジュール（３００）を取得するステップであって、前記信頼できないプログラムモジュール（３００）は１又は複数のコンピューティングリソース（３１２及び３５０）にアクセスするように構成されているステップと、
前記信頼できないプログラムモジュール（３００）の１又は複数のターゲットコンピューティングリソース（３１２及び３５０）を判定するステップであって、前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）は、前記プログラムモジュール（３００）の前記実行可能命令のセットが実行される際に、前記信頼できないプログラムモジュール（３００）がアクセスすることを求めるコンピューティングリソース（３１２及び３５０）であるステップと、
１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を前記信頼できないプログラムモジュール（３００）に提供し、前記提供された１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を介して、前記信頼できないプログラムモジュールが前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）へのアクセスを得るステップであって、前記１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）は前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）に関連付けられているステップと、
それらの１又は複数のターゲットコンピューティングリソース（３１２及び３５０）に関連付けられた前記１又は複数の信頼できるローカルアクセスオブジェクト（３３２、３３３、３３６、３３８、及び３４０）を介してのみ前記プログラムモジュールに前記１又は複数のターゲットコンピューティングリソース（３１２及び３５０）へのアクセスを許可するステップと
を有することを特徴とするプロセッサ可読媒体。
前記信頼できないプログラムモジュール（３００）はデバイスドライバ（３００）であることを特徴とする請求項９に記載の１又は複数の媒体。