JP6768710B2 - ファームウェア関連イベント通知 - Google Patents

Description

本開示は、デバイス内通信に関し、より詳細にはファームウェアにおいて発信された通知をオペレーティングシステムに伝搬するためのデバイスにおけるシステムに関する。

コンピューティングデバイスにおいて、“プラットフォーム”は、オペレーティングシステム（OS）が実行可能な機器及び/又はソフトウェアを含みうる。例えば、デバイスが初期化される（例えば、起動される、再起動されるなど）とき、ファームウェアは、OSがプラットフォームにおける機器とインタラクトするために利用しうるソフトウェアドライバ、ユーティリティ、インタフェースなどを提供するため、プラットフォームにロードしうる。デバイス初期化中にロードされたファームウェアは、従来、デバイスのベースライン処理のために提供される。しかしながら、コンピューティングデバイスの技術が進化するに従って、ファームウェアによって提供される機能も進化する。現代のファームウェアは、デバイスの動作及びOS/ハードウェアインタラクティビティに不可欠なドライバ、ユーティリティなどをロードするだけでなく、プロテクト手段などのエンハンスされた機能を提供しうる。例えば、ファームウェアは、その後にロードされたプログラムを検証する既知の良好なプログラムをロードし、次いで、これらの既知の良好なプログラムをデバイスのメモリ内のセキュアな領域において暗号化し、それによって、悪意のあるソフトウェア（例えば、マルウェア）が（例えば、OSレベルのセキュリティソフトウェアがロードされていないときの初期化中）最も脆弱であるとき、コンピューティングデバイスを危険にさらすことができないことを確実にする。さらに、ファームウェアは更に、コンピューティングデバイスにおける機器の変更（例えば、周辺機器の追加及び削除）を監視し、機器の変更が安全である（例えば、追加された機器がホワイトリストに登録されているか）を判断することが可能であってもよい。

上記の機能の利点は容易に明らかであるが、このタイプの機能を実現する方法は明らかでない。UEFI（Universal Extensible Firmware Interface）に基づくファームウェアは、上述したような機能を効率的に実現しうる“ランタイム”機能（例えば、コンピューティングデバイスが動作している間はバックグラウンドで動作するプログラム）を提供してもよく、従って、コンピューティングデバイスの性能に悪影響を与えない。これは、機能的かもしれないが、ソフトウェアインタプリタがコードを実行する必要があるためより大きな処理オーバヘッドを招く、ACPI（Advanced Configuration and Power Interface）規格に基づくなどのバイトコードと比較されてもよい。処理を実行する際、ファームウェアは、例えば、潜在的なセキュリティ侵害、デバイスにおけるハードウェア変更などの様々なイベントをOSに通知する必要があり得る。しかしながら、UEFIに基づくファームウェアは、より効率的であるが、デバイスにおけるOSに通知を生成するための効果的な手段を有さない。

請求される主題における各種実施例の特徴及び効果は、同様の数値が同様のパーツを指定する図面を参照して以下の詳細な説明が進むに従って明らかになるであろう。
図1は、本開示の少なくとも1つの実施例によるファームウェア関連イベント通知のために構成される一例となるデバイスを示す。 図2は、本開示の少なくとも1つの実施例による利用可能なデバイスの一例となる構成を示す。 図3は、本開示の少なくとも1つの実施例によるインタラプトソースクエリの一例を示す。 図4は、本開示の少なくとも1つの実施例による拡張可能ファームウェアインタフェース通知（EFIN）テーブルの一例を示す。 図5は、本開示の少なくとも1つの実施例による拡張可能ファームウェアインタフェースプラットフォーム通信チャネル（PCC）共有メモリ空間の一例を示す。 図6は、本開示の少なくとも1つの実施例による一例となる拡張可能ファームウェアインタフェース物理ベース制御レジスタ及び拡張可能ファームウェアインタフェースランタイム範囲制御レジスタを示す。 図7は、本開示の少なくとも1つの実施例によるファームウェア関連通知を生成及び受信するための一例となる処理を示す。 図8は、本開示の少なくとも1つの実施例によるデバイスにおける周辺トポロジ変更に関するイベント通知を生成するための一例となる処理を示す。 以下の詳細な説明は例示的な実施例を参照することにより進むが、それの多数の代替、修正及び変形が当業者に明らかであろう。

本開示は、ファームウェア関連イベント通知を対象とする。一般に、デバイスは、プラットフォーム上で動作するよう構成されたオペレーティングシステム（OS）を少なくとも含みうる。最初に、デバイスの初期化（例えば、起動）中、プラットフォームにおけるファームウェアモジュールは、デバイスにおけるファームウェアコンフィギュレーションテーブルに少なくとも1つのグローバルに一意的な識別子（GUID）をロードしてもよい。通常の動作中、OSには、プラットフォームにおいて行われる特定のイベントが通知される必要がありうる。イベントの発生（例えば、周辺トポロジ変更に基づく）において、ファームウェアモジュールは、メッセージングインタフェースとやりとりし、OSに通知を生成させてもよい。例えば、ファームウェアモジュールは、イベントに関連する少なくとも1つのGUIDを、デバイスにおける共有メモリ空間内に存在するプラットフォーム通知テーブルにロードし、プラットフォーム通知テーブルにおけるステータスフィールドにプラットフォーム通知ビットを設定してもよい。その後、OSにおけるOS管理モジュール（OSMM）によって検出されうる通知が生成されてもよい。OSMMは、例えば、プラットフォーム通知テーブルに問い合わせることによって通知のソースを確立してもよい。プラットフォーム通知ビットが設定されたと判断すると、OSMMは、プラットフォーム通知テーブル及びファームウェア構成テーブルにおいて設定されているGUIDを比較してもよい。2つのテーブルにおける少なくとも1つのGUIDが一致すると判断された場合、サービスが、一致したGUIDに基づき呼び出されてもよい。あるいは、サービスは、（例えば、OSMMがGetVariable（）コマンドを発行したことに応答して返される）デバイスに設定されたファームウェア変数に基づき呼び出されてもよい。本開示と整合して、少なくともプラットフォーム通知テーブルは、例えば、物理範囲テーブル及び物理マスクテーブルを使用して、不正な変更からプロテクトされてもよい。

少なくとも1つの実施例では、ファームウェア関連イベント通知を生成する例示的なデバイスは、メモリモジュール、ファームウェアモジュール及び処理モジュールを少なくとも備えてもよい。メモリモジュールは、少なくとも共有メモリ空間を含んでもよい。ファームウェアモジュールは、メッセージングインタフェースの少なくとも一部を共有メモリ空間にロードし、メッセージングインタフェースにデバイスにおけるOSに対する通知を生成させるものであってもよい。処理モジュールは、少なくともOSから受信された命令に基づきデバイスにおいて処理を実行するものであってもよく、オペレーティングシステムは、メッセージングインタフェースによって提示される通知に少なくとも反応するOSMMを含む。

デバイスの初期化中、ファームウェアモジュールは、ファームウェアコンフィギュレーションテーブルへの少なくとも1つのグローバルに一意的な識別子及び対応するサービス識別子エントリのロード、あるいは、少なくとも1つのファームウェア変数の生成の少なくとも1つをするものであってもよい。ファームウェアコンフィギュレーションテーブルは、例えば、UEFI（Unified Extensible Firmware Interface）規格に基づくものであってもよい。ファームウェアモジュールは、通知が生成される前に、少なくとも1つのGUIDを共有メモリ空間におけるプラットフォーム通知テーブルにロードするものであってもよい。プラットフォーム通知テーブルは、例えば、ACPI（Advanced Configuration and Power Interface）規格に基づくものであってもよい。この通知は、例えば、システム制御インタラプト（SCI）であってもよい。少なくとも1つの一例となる実施形態では、プラットフォーム通知テーブルは、物理ベース制御レジスタ又は物理マスク制御レジスタの少なくとも1つによってプロテクトされてもよい。ファームウェアモジュールは更に、プラットフォーム通知テーブルのステータスフィールドに少なくとも1つのプラットフォーム通知ビットを設定するものであってもよい。

少なくとも1つの実施例では、OSMMは、少なくともプラットフォーム通知テーブルを問い合わせることによって通知のソースを処理モジュールに発見させるものであってもよい。プラットフォーム通知ビットがプラットフォーム通知テーブルに設定されていると判断したことに応答して、OSMMは、プラットフォーム通知テーブルにおける少なくとも1つのGUIDがファームウェアコンフィギュレーションテーブルにロードされた何れかのGUIDと同じであるか処理モジュールに判断させるものであってもよい。プラットフォーム通知テーブルにおける少なくとも1つのGUIDがファームウェアコンフィギュレーションテーブルにロードされた何れのGUIDとも同じでないと判断したことに応答して、OSMMは、処理モジュールにファームウェアコンフィギュレーションテーブルからファームウェア変数を要求させるものである。その後、OSMMは、ファームウェアコンフィギュレーションテーブルにおけるGUID又はリターンされたファームウェア変数と一致すると判断されたプラットフォーム通知テーブルにおけるGUIDに対応するサービス識別子に基づき、オペレーティングシステムにおける少なくとも1つのサービスを処理モジュールに呼び出させるものであってもよい。

少なくとも1つの実施例では、通知は、デバイスにおいて検出された周辺トポロジ変更に基づき生成されてもよい。本開示と整合して、ファームウェア関連通知を生成するための例示的な方法は、デバイスにおいてファームウェアコンフィギュレーションテーブルを設定し、デバイスにおけるプラットフォームからの通知がデバイスにおけるオペレーティングシステムのために生成される必要があるか判断し、デバイスにおいてプラットフォーム通知テーブルを設定し、当該通知を生成することを含んでもよい。本開示と整合して、ファームウェア関連通知を受信するための例示的な方法は、デバイスにおけるオペレーティングシステムで通知を受信し、デバイスにおけるプラットフォーム通知テーブルに少なくとも問い合わせることに基づき通知のソースを発見し、プラットフォーム通知ビットがプラットフォーム通知テーブルのステータスフィールドに設定されたか判断することを含むものであってもよい。

図1は、本開示の少なくとも1つの実施例によるファームウェア関連イベント通知のために構成される例示的なデバイスを示す。まず、以下は、ファームウェア（例えば、UEFI）を実現するため、デバイス内通信（例えば、ACPI）を提供しうるインタフェースを実現するためなどの特定の技術を参照するか、あるいは、それらに共通に関連する用語を使用しうる。これらの参照は、ここでは説明のためにのみ利用され、本開示に整合する実施例を何れか特定の実現形態の方法に限定することを意図するものではない。これらの例示的な技術は実施例を理解するための基礎を提供するが、実際の実現形態は、現在存在するか、あるいは、将来的に開発される他の同様の技術を利用してもよい。

一般に、デバイス100は、少なくともデータ入力を受信し、データを処理し、出力を生成するよう構成可能なリソースを含む任意の装置であってよい。装置100の具体例は、限定されることなく、Google CorporationのAndroid（登録商標）OS、Apple CorporationのiOS（登録商標）若しくはMac OS（登録商標）、Microsoft CorporationのWindows（登録商標）OS、Linux FoundationのTizen（登録商標）OS、Mozilla ProjectのFirefox（登録商標）OS、Blackberry CorporationのBlackberry（登録商標）OS、Hewlett-Packard CorporationのPalm（登録商標）OS、Symbian FoundationのSymbian（登録商標）OSなどに基づくセルラハンドセット若しくはスマートフォン、Apple CorporationのiPad（登録商標）、Microsoft CorporationのSurface（登録商標）、Samsung CorporationのGalaxy Tab（登録商標）、Amazon CorporationのKindle（登録商標）、Intel Corporationの低電力チップセットを含むUltrabook（登録商標）などのモバイルコンピューティングデバイス、ネットブック、ノートブック、ラップトップ、パームトップなど、Samsung CorporationのGalaxy Gear（登録商標）などの腕時計型フォームファクタコンピューティングデバイス、Google CorporationのGoogle Glass（登録商標）などのアイウエアフォームファクタコンピューティングデバイス/ユーザインタフェース、Samsung CorporationのGear VR（登録商標）などのバーチャルリアリティ（VR）ヘッドセットデバイス、Oculus VR CorporationのOculus Rift（登録商標）などのウェアラブルデバイス、デスクトップコンピュータ、サーバ、高性能コンピューティング（HPC）アーキテクチャで編成されたコンピューティングデバイスのグループ、スマートテレビ若しくは他のタイプの“スマート”デバイス、Intel CorporationのNext Unit of Computing（NUC）プラットフォームなどの（例えば、スペース限定アプリケーション、TVセットトップボックスなど）スモールフォームファクタコンピューティングソリューションなどのモバイル通信デバイスを含んでもよい。

デバイス100は、少なくともプラットフォーム102及びOS104を有してもよい。プラットフォーム102は、例えば、OS104が実行することができるハードウェアリソース及びハードウェアにより実現されるソフトウェア（例えば、ファームウェア）を少なくとも含んでもよい。本開示と整合して、インタフェース106は、プラットフォーム102における少なくともファームウェアモジュール108がOS104におけるOS管理モジュール（OSMM）110とやりとりする方法を提供しうる。ファームウェアモジュール108は、デバイス100の初期化によって（例えば、初期起動中、再起動中など）、特定のコード（例えば、UEFIなどのランタイムアプリケーション）を実現するよう構成可能なハードウェア（例えば、不揮発性メモリ）を含んでもよい。OSMM110は、プラットフォーム関連イベントを処理するOS104に少なくとも1つのアプリケーション、ユーティリティ、サービスなどを含んでもよい。ファームウェアモジュール106とOSMM110との間のインタラクションを容易にするため、インタフェース106は、少なくともメッセージングインタフェース112及び共有メモリ空間114を含んでもよい。メッセージングインタフェース112は、限定されないが、OSMM110によって観察可能な通知を生成することができるACPIなどのメッセージングシステムを含んでもよい。共有メモリ空間114は、ファームウェアモジュール108及びOSMM110にアクセス可能なメモリにおける少なくとも1つの場所を含んでもよい。

処理の一例では、デバイス100の初期化中、ファームウェアモジュール108は、少なくともデバイス100内でグローバルに一意的な識別を確立するのに使用されうるデータの何れかの配置を含みうるGUIDを含むデータエントリ（例えば、タプル）と、116において示されるようなOS104によって（例えば、OSMM110によって）ロードされうるサービスを示す対応するポインタとをロードしてもよい。少なくとも1つの実施例では、データエントリは、ファームウェアコンフィギュレーションテーブルにロードされてもよい。プラットフォーム102の構成の変更、セキュリティ問題等のプラットフォーム102において発生したイベントに応じて、ファームウェアモジュール108は、118に示されるように、メッセージングインタフェース112がOS104に通知を生成することを要求してもよい。その後、メッセージングインタフェース112は、120に示されるように、OS104に対する通知を生成するよう構成されてもよい。少なくとも1つの実施例では、当該通知はインタラプトであってもよい。このとき、当該通知は、OSMM110に、122で示されるように少なくとも共有メモリ空間114に問い合わせさせ、当該通知のソースを検出してもよい。このプロセスの一部は、通知に対応するテーブルにおいて構成されたGUIDが、デバイスの初期化中にファームウェアコンフィギュレーションテーブルにおいて当初構成されたGUIDと一致するか判断することに関連しうる。何れかのGUIDが一致すると判定された場合、一致したGUID（例えば、ブートコンフィギュレーション116中にロードされたデータに基づき）に対応するサービスが、呼び出されてもよい。そうでない場合、例えば、ブートコンフィギュレーション116の間に設定されたファームウェア変数を取得するためのコマンドを利用し、リターンされたファームウェア変数に対応しうる何れかのサービスを呼び出すなどの代替的な処理が行われてもよい。上記の処理及び構成のより具体的な例が図3〜8において説明される。

各種効果が、図1において特定される処理及び構成に従って実現されうる。本開示と整合して、OS104におけるファームウェアトリガなサービスの実行を可能にする実施例が提供される。これは、いくつかの実施例では、追加のハードウェアベースプロテクションを含むものであってもよい新たな範囲レジスタのクラスを介し実現されてもよい。上記の処理における信頼性は、例えば、Intel Corporationのものなどのいくつかのマイクロプロセッサにおいて見つけられるCSME(Converged Security and Management Engine)などのセキュリティコプロセッサによるUEFIイメージのデジタル署名及び/又はチャレンジ/レスポンスを介し実現されてもよい。

この実行とプロテクションとの組み合わせは、攻撃についての懸念に同時に対処しながら、ファームウェアモジュール108に（例えば、UEFIランタイムに）追加の機能が組み込まれることを可能にしうる。“リング”として異なるレベルの特権及び思考のコンピュータ階層プロテクション理論では、最も高い特権のソフトウェア/ファームウェアは“リング0”において実行されてもよい。リング0におけるOSカーネルドライバとファームウェアモジュール108のランタイム要素との共置は、ファームウェアランタイムを攻撃者が対象とするのに特に魅力的で脆弱にする。ファームウェアランタイムを強化することは、追加のランタイム機能についてファームウェアランタイム（例えば、UEFIランタイム）を安全に活用する能力を提供しうる。このため、新たなプラットフォーム能力が、GUID及び対応するコールを利用して公開されてもよい。

従来、新しいサービスは、バスドライバ、命令コール（例えば、CPUIDリーフ）をサポートするための専用のプロセッサレジスタ及び柔軟なプラットフォーム開発を禁止する他のタイプの特殊化を必要としていた。これの具体例は、典型的にはACPIソース言語（ASL）により実現されるが、ACPIマシン言語（AML）仮想マシンのセマンティクスによって制約されうるアドレス空間ミラーリングを含む。システム管理モード（SMM）へのポートトラップの従来技術は、大規模システム（例えば、SMMの遅延が120μs以下に維持されるべき数百のコアを含む）に有害な影響を及ぼしうる。

本開示と整合する実施例は、プラットフォーム102において行われるイベントをOS104に通知するための非同期通知機構がないことから生じる問題を解決しうるものであり、これに応答して、OS104はプラットフォーム102とのインタラクション（例えば、イベントに関する情報を取得するため、イベントを処理するため、プラットフォーム102にコマンドを送信するためなど）を容易にするためのアプリケーションプログラムインタフェース（API）又はサービス（例えば、EFI変数サービス）を呼び出してもよい。プラットフォーム102がOS104に通知する必要がある具体例は、アドレスベースのミラーリング（例えば、Intel CorporationのXeonファミリなどのプロセッサチップセットに基づくサーバプラットフォーム）である。アドレスミラーリングは、プロセッサがメモリフォルト中に1つのミラーリングされたチャネルから別のミラーリングされたチャネルにスイッチしてもよい点で、サーバアプリケーションにおけるデータインテグリティを強化するのに役立ちうる。ミラーリングされたメモリ範囲は、OS104がミラーリングされたメモリ範囲にクリティカルコード（例えば、カーネルスペース）をロードして信頼性を高めることができるように、デバイス100の初期化中にOS104に公開されてもよい。しかしながら、ミラーが（例えば、メモリ障害のために）フェイルオーバ中に“破損”すると、OS104に当該イベントが通知されてもよい。本開示と整合して、プラットフォーム102におけるファームウェアモジュール108のランタイム部分（例えば、UEFIランタイム）は、OS104に当該イベントを通知可能であってもよい。当該通知に応答して、OS104は、プラットフォームファームウェアAPI、UEFI変数に基づくサービスなどを呼び出し、当該通知の理由を発見し、それを処理してもよい。他の例では、OS104は、アドレスベースのメモリ検査及び訂正処理（例えば、パトロールスクラブ）の開始を要求してもよく、プラットフォーム102は、スクラブの終了時にOS104に通知することが必要とされてもよい。

ここに開示される各種実施例は、プラットフォームがACPI名前空間ベースの通知に依拠する必要なく、OS104の注意を取得する方法を提供しうる。その代わりに、UEFIフレームワークの豊富さは、解釈されたASLコードの非常に限られた能力に依拠する代わりに、活用されてもよい。ASLコードの限定は、現代の電子機器（例えば、マイクロプロセッサ）において利用可能なより高度な機能の展開を厳しく制限する可能性がある。ここに開示される各種実施例は、プラットフォームイベントのためのASL名前空間コードの代わりにUEFIサービスの利用を可能にしうる。

リング0特権によって挿入されうる悪意のあるソフトウェア（マルウェアなど）に関するセキュリティ上の懸念が存在する場合、OS通知に関連するテーブルにおけるエントリの切り離された又は埋め込まれたシグネチャが利用されてもよく（例えば、コールに対するAuthenticodeベースのシグネチャに基づく）、これにより、より安全なディスパッチャが、UEFIセキュアブートにおけるプラットフォームキーなど、GUIDにより識別される実行可能ファイルがいくつかの権限につながりうることを確実にしうる。これまで、セキュア管理モード（SMM）は、ランタイム時にクリティカルコードをプロテクトすることができた。しかしながら、特定のサーバ上でSMMを呼び出すことは遅延/スケーリングの問題を生じさせうるという懸念がある。そのような懸念は、例えば、Intel CorporationのいくつかのプロセッサチップセットにおいてサポートされるCSME(Converged Security Manageability Engine)などの信頼される実行環境（TEE）にUEFIランタイムホスト埋め込みコントローラインタフェース（HECI）コール（例えば、専用のHECIドライバを介し）に対する認証を移すことによって軽減されうる。このとき、CSMEはファームウェアモジュール108におけるセキュリティコールバックハンドラによるチャレンジ/レスポンスを実行してもよい。さらに、UEFIは、CSMEへのプラットフォーム上の周辺接続（例えば、ストリーム解析装置）を公開してもよく、これにより、CSMEにおけるTEEが未承認のデータ取得を軽減するために用意された“ホワイトリスト”のデバイスと新たに追加された周辺機器とを比較することを可能にする。

図2は、本開示の少なくとも1つの実施例による利用可能なシステムの構成例を示す。本開示におけるアイテム番号の後にアポストロフィを含むこと（例えば、100’）は、特定のアイテムの例示的な実施例が示されていることを示すものであってもよい。例えば、デバイス100’は、図1に開示されたアクティビティの何れか又は全てを実行可能であってもよい。しかしながら、デバイス100’は、本開示と整合する実施例において利用可能な装置の一例としてのみ提示され、ここに開示された実施例の何れかを実現形態の特定の方法に限定することを意図するものでない。

デバイス100’は、例えば、デバイスの動作を管理するためのシステムモジュール200を有してもよい。システムモジュール200は、例えば、処理モジュール202、メモリモジュール204、電源モジュール206、ユーザインタフェースモジュール208及び通信インタフェースモジュール210を含んでもよい。デバイス100’は更に、通信モジュール212を含んでもよい。通信モジュール212は、システムモジュール200から分離して示されているが、図2に示された例示的な構成は説明の便宜のためにのみ提供されたものである。通信モジュール212に関連する機能の一部又は全てはまた、システムモジュール200に組み込みこまれてもよい。

デバイス100’において、処理モジュール202は、プロセッサに関連するサポート回路（例えば、ブリッジングインタフェースなど）と共に、別個のコンポーネントに配置された1つ以上のプロセッサ、又は、あるいは単一のコンポーネントにおける（例えば、システム・オン・チップ(SoC)コンフィギュレーションにおける）1つ以上の処理コアを含んでもよい。例示的なプロセッサは、限定されることなく、Pentium、Xeon、Itanium、Celeron、Atom、Quark、Core iシリーズ、Core Mシリーズ製品ファミリ、Advanced RISC（例えば、縮小命令セット計算）マシン又は“ARM”プロセッサなどにおけるものを含むIntel Corporationから入手可能な各種x86ベースマイクロプロセッサを含んでもよい。サポート回路の例は、処理モジュール202がデバイス100’における異なる速度、異なるバスなどで動作しうる他のシステムコンポーネントとやりとりしうるインタフェースを提供するよう構成されるチップセット（例えば、Intel Corporationから入手可能なNorthbridge、Southbridgeなど）を含んでもよい。さらに、サポート回路に共通に関連する機能の一部又は全てはまた、プロセッサと同じ物理パッケージ（例えば、Intel Corporationから入手可能なSandy Bridgeファミリのプロセッサなど）に含まれてもよい。

処理モジュール202は、デバイス100’において様々な命令を実行するよう構成されうる。命令は、処理モジュール202にデータの読み取り、データの書き込み、データの処理、データの形式化、データの変換、データの変形などに関連するアクティビティを実行させるよう構成されるプログラムコードを含んでもよい。情報（例えば、命令、データなど）はメモリモジュール204に格納されてもよい。メモリモジュール204は、固定又は取外し可能な形式でランダムアクセスメモリ（RAM）及び/又は読み出し専用メモリ（ROM）を含みうる。RAMは、例えば、スタティックRAM（SRAM）又はダイナミックRAM（DRAM）などのデバイス100’の動作中に情報を保持するよう構成された揮発性メモリを含んでもよい。ROMは、デバイス100’が起動されたときに命令を提供するようBIOS、UEFIなどに基づき構成される不揮発性（NV）メモリモジュール、電子プログラマブルROM（EPROM）などのプログラマブルメモリ、フラッシュなどを含んでもよい。他の固定/着脱可能メモリは、限定されることなく、例えば、フロッピー（登録商標）ディスク、ハードドライブなどの磁気メモリ、ソリッドステートフラッシュメモリ（例えば、埋め込みマルチメディアカード（eMMC）など）などの電子メモリ、リムーバブルメモリカード若しくはスティック（例えば、マイクロストレージデバイス（uSD）、USBなど）、CD-ROM、DVD、Blu-Rayディスクなどの光メモリを含んでもよい。

電力モジュール206は、内部電源（例えば、バッテリ、燃料電池など）及び/又は外部電源（例えば、電気機械若しくは太陽発電機、電力グリッド、外部燃料電池など）と、動作するのに必要な電力をデバイス100’に供給するよう構成される関連する回路とを含んでもよい。ユーザインタフェースモジュール208は、例えば、様々な入力機構（例えば、マイクロフォン、スイッチ、ボタン、ノブ、キーボード、スピーカ、接触感知面、画像をキャプチャし、及び/又は近接性、距離、動き、ジェスチャ、向き、バイオメトリックデータなどを検知するよう構成される1つ以上のセンサ）と、様々な出力機構（例えば、スピーカ、ディスプレイ、点灯/点滅インジケータ、振動、動きのための電気機械コンポーネントなど）など、ユーザがデバイス100’とやりとりすることを可能にするハードウェア及び/又はソフトウェアを含んでもよい。ユーザインタフェースモジュール208におけるハードウェアは、デバイス100’内に組み込まれてもよく、及び/又は有線又は無線通信媒体を介しデバイス100’に結合されてもよい。ユーザインタフェースモジュール208は、例えば、デバイス100’がユーザインタフェースモジュール208を含まず、代わりにユーザインタフェース機能のための他のデバイス（例えば、管理端末）に依拠するサーバ（例えば、ラックサーバ、ブレードサーバなど）である。

通信インタフェースモジュール210は、有線及び/又は無線通信をサポートするよう構成されたリソースを含みうる通信モジュール212のパケットルーティング及び他の制御機能を管理するよう構成されてもよい。いくつかの例では、デバイス100’は、中央化された通信インタフェースモジュール210によって管理される複数の通信モジュール212（例えば、有線プロトコル及び/又は無線ラジオのための別個の物理インタフェースモジュールを含む）を含みうる。有線通信は、例えば、イーサネット（登録商標）、USB、Firewire、Thunderbolt、DVI（Digital Video Interface）、HDMI（High-Definition Multimedia Interface）など、シリアル及びパラレル有線媒体を含んでもよい。無線通信は、例えば、近接無線媒体（例えば、RFID（RF Identification）又は近距離通信（NFC）規格、赤外線（IR）などに基づく無線周波数（RF））、短距離無線媒体（例えば、ブルートゥース、WLAN、Wi-Fiなど）、長距離無線媒体（例えば、セルラ広域無線通信技術、衛星ベース通信など）、音波を介した電子通信などを含んでもよい。一実施例では、通信インタフェースモジュール210は、通信モジュール212においてアクティブである無線通信が互いに干渉するのを防止するよう構成されてもよい。この機能を実行する際、通信インタフェースモジュール210は、例えば、送信を待つメッセージの相対的優先度に基づき、通信モジュール212のアクティビティをスケジューリングしてもよい。図2に開示された実施例は、通信インタフェースモジュール210が通信モジュール212とは別個であることを示しているが、通信インタフェースモジュール210及び通信モジュール212の機能が同じモジュールに組み込まれることも可能でありうる。

本開示と整合して、メモリモジュール204は、デバイス初期化中に少なくともファームウェアランタイムコード（例えば、UEFIランタイム）をメモリモジュール204におけるRAMにロードし、少なくとも1つのファームウェアコンフィギュレーションテーブルを設定するファームウェアモジュール108’に対応するNVメモリを少なくとも有してもよい。OS104は、以降に（例えば、OSMM110’と共に）RAMにロードされてもよい。プラットフォーム102がイベントをOS104に警告する必要があるとき、ファームウェアモジュール108’のランタイム部分は、メッセージングインタフェース112’（例えば、ACPI）とやりとりして、OS104に対する通知が生成される前に構成されるべき少なくとも1つのテーブルを処理モジュール202に構成させてもよい。少なくとも1つの実施例では、テーブルは、メモリモジュール204における共有メモリ空間112’内に存在するプラットフォーム通知テーブルであってもよい。

図3は、本開示の少なくとも1つの実施例によるインタラプトソースクエリの一例を示す。例示的なインタラプトクエリ124’は、システム制御インタラプト（SCI）に対応するソースを決定するためトラバースされうる様々なテーブルを示す。最初に、構成EFI通知（EFIN）テーブル300は、ACPIテーブル実施ガイドラインに基づくものであってもよい。EFINテーブル300は、少なくともACPIヘッダと、少なくとも1つのEFIN PCC部分空間識別子（例えば、図3において示されるように“X”）とを含んでもよい。対応するプラットフォーム通信チャネルテーブル（PCCT）が302において示される。典型的には、プラットフォーム102がSCIを利用してOS104に通知するとき、OS104は、プロセッサコア論理チップセット（例えば、South Bridge）におけるACPIステータスレジスタを読み出して、通知の理由を特定し、その後、対応するASL名前空間メソッドを呼び出す。例えば、非ネイティブなPCIe（Peripheral Component Interconnect Express）の“Hotplug”イベント（例えば、デバイス100が動作している間のPCIe機器の追加又は取り外し）は、ステータスビットを設定し、当該ステータスに対応するよう決定されたASLコードを評価することによってOSMM110に応答させるSCIをOS104にトリガする。PCC機構はACPI5.0に追加されたものであり、これにより、OS104はまた、単にASLメソッドに加えてテーブルを評価してもよい。ACPI PCCT302は、ACPIヘッダ及び0・・・nからのPCC部分空間構造の配列を少なくとも含むACPIテーブルである。各PCC部分空間は、PCCT302におけるEFIN PCC部分空間構造のインデックス位置に対応しうる識別子を含んでもよい（例えば、図3の例では、識別子XのPCC部分空間構造は、対応するPCC共有メモリ空間306を特定しうるYのインデックスを有してもよい）。304に示されるように、識別子XのPCC部分空間構造は、構造のタイプ及び長さ、共有メモリ空間のベースアドレス及び長さ、並びにドアベルレジスタ値を含んでもよい。ドアベルレジスタは、OSMM110にSCIのソースを示してもよい（例えば、ソースは、実行中のコードを中断するため、OS 104の“ドアベルを鳴らし”、ドアベルレジスタによって識別されてもよい）。

PCC共有メモリ空間306は、プラットフォーム102とOS104との間でコマンド及びパラメータをわたすためのメールボックスとして機能するいくつかの機能に固有のテーブルを含んでもよい。308に示される少なくとも例示的なテーブル構造はまた、“プラットフォーム通知テーブル”として参照されうる。308に示されるように、識別子Xに対応する共有メモリ空間は、例えば、“EFIN”のシグネチャ、コマンドフィールド310、ステータスフィールド312、GUIDの数及びGUIDのリストを含んでもよい。動作時には、ステータスフィールド312は、設定されたときに、OS 104（例えば、OSMM 110）に、314で示されるように共有メモリ空間に設定されたGUIDのリストを検査するようトリガしうるプラットフォーム通知ビットを少なくとも含みうる。デバイスの初期化中、共有メモリ空間におけるGUIDのリストは、ファームウェアコンフィギュレーションテーブル（例えば、EFIシステムテーブル）にロードされたGUIDと比較されてもよい。共有メモリ空間にロードされたGUIDの何れかがファームウェアコンフィギュレーションテーブルのGUIDと一致すると判定された場合、（例えば、一致するGUIDに対応するポインタによって）ファームウェアコンフィギュレーションテーブルにおいて識別された少なくとも1つのサービスが、316に示されるように呼び出されてもよい。そうでなければ、少なくとも1つの実施例では、OSMM 110は、共有メモリ空間にリストされたGUIDを使用してGetVariable（）処理を実行し、そして、何れかのリターンされた変数に対応するサービスを呼び出してもよい。

図4は、本開示の少なくとも1つの実施例による例示的なEFINテーブルを示す。例示的なACPI EFINテーブル300’は、少なくともACPIヘッダ及びEFIN固有エントリを含んでもよい。ACPIヘッダは、シグネチャ（例えば、“EFIN”）、テーブルの終わり（EOT）におけるEFIN固有エントリフィールドの数を含みうるEFINのバイトの長さ、EFINテーブル番号、“有効な”テーブルに対して総和がゼロであるべきEFINテーブルのチェックサム、元の機器メーカ（OEM）の識別情報（ID）（例えば、デバイス100又はデバイス100にインストールされた機器に対する）、OEMテーブルID（例えば、デバイス100又はデバイス100にインストールされた機器のメーカモデル識別情報を示すものであってもよい）、供給されたOEMテーブルIDに対するEFINテーブルに対応するOEM改訂番号、及びEFINテーブルを作成したユーティリティ（例えば、プログラム、サービスなど）のベンダIDを示す作成者改訂を含んでもよい。EFIN固有エントリは、例えば、PCCT302における対応するPCC部分空間構造を識別するのに利用されうる少なくとも1つのEFIN PCC識別子を含み得る。

図5は、本開示の少なくとも1つの実施例による例示的なEFI PCC共有メモリ空間を示す。PCC共有メモリ空間308’の一例が図5に示され、コマンドフィールド310’及びステータスフィールド312’の更なる吹き出しに続く。PCC共有メモリ空間308’は、例えば、シグネチャフィールド（例えば、それがEFINの共有メモリ空間であることを示す“EFIN”のシグネチャを含みうる）、PCCコマンドフィールド（例えば、ACPIにより定義されたフォーマットにおける）及びステータスフィールド（例えば、ACPIにより定義されたフォーマットにおける）を含んでもよい。少なくとも1つの実施例では、例示的な共有メモリ空間308’のサブセクションは“通信空間”として定義されてもよく、プラットフォーム102によってOS 104に通知される少なくともGUIDが、GUIDのリストにおけるGUIDの総数の表示と共にリストされうる。

共有メモリ空間308’におけるコマンドフィールドに対応する一例となる吹き出しテーブルが310’に示される。コマンドフィールド310’は、例えば、コマンドビット列、予約ビット列及び生成SCIビット列を含んでもよい。少なくとも1つの実施例では、生成SCIビット列における1つ以上のビットが、OS 104に対するSCI 104を生成するため設定されてもよい。ステータスフィールドに対応する吹き出し一例となるテーブルが312’に示される。ステータスフィールド312’は、例えば、コマンド完了ビット、SCIドアベルビット、エラービット、プラットフォーム通知ビット及び予約ビット列を含んでもよい。SCIドアベルビットは、ソースクエリ中にソース及びSCIをOSMM110に通知するのに利用されてもよく、プラットフォーム通知ビットは、通知に応答するため呼び出される必要のあるサービスを決定するため（例えば、プラットフォーム102において行われたイベントに対処するため）、OSMM110がGUIDのリストを検査する必要があることを示すものであってもよい。

図6は、本開示の少なくとも1つの実施例による例示的なEFI物理ベース制御レジスタ及びEFIランタイム範囲制御レジスタを示す。本開示に整合して、プラットフォーム通知テーブルにおける情報の修正は、OS104への通知の生成をトリガしてもよい。この点に関して、デバイス100におけるセキュリティを含む意図しない効果を有する通知をトリガすることが可能であってもよい。例えば、デバイス100におけるマルウェアは、当該マルウェアがOS 104から情報を取得するか、あるいは、OS 104に対する制御を取得することを可能にしうるGUIDに説yぞくされるサービスをOSMM 104に実行させることが可能である。

セキュリティ対策は、この種の予期しない動作をプロテクトするため、本開示に整合する実施例において実現されてもよい。例えば、ファームウェアモジュール108のランタイム要素（例えば、UEFIドライバ）は、例えば、Intel CorporationのAuthenticode DLL(Dynamic Linked Library）を用いて署名されてもよい。UEFIランタイムはまた、例えば、Intel Corporationのセキュアガードエクステンション（SGX）を用いて実現されるTEEにおいて実行されるシステムセキュリティ（例えば、ウイルスプロテクションプログラム）のセキュア部分とチャレンジ/レスポンスインタラクションを実行可能であってもよい。この種の処理は、TEEにおいて実行される既知の良好なアプリケーションが、UEFIランタイムが良好であると知られている（例えば、損なわれていない）ことを検証することを可能にする。

単独で、あるいは、上記と組み合わせて、範囲レジスタ（例えば、メモリタイプ範囲レジスタ（MTRR）又はシステム管理範囲レジスタの方法において）が、EFIランタイムサービスへの不正な書き込みアクセスを防ぐため利用されてもよい。EFIランタイム範囲レジスタ（RTRR）600の具体例が、図6の602及び604に示される。これらのレジスタは、スレッド毎に1つであってもよく、OS 104がデバイス100の制御（例えば、OSハンドオフ）を取得する前にファームウェアモジュール108によってセットアップされてもよい。特に、レジスタ602及び604は、この領域が修正されることからセキュアにするため、システムブートファームウェアがOSハンドオフの前にプログラムするモデル固有レジスタ（MSR）であってもよい。少なくとも1つの実施例では、IA32_MTRRCAPレジスタのビット12は、RTRRがデバイス100においてサポートされているかファームウェアモジュール108に示すものであってもよい。例示的な物理ベース制御レジスタ602及び例示的なランタイム範囲物理マスクレジスタが、対象とされる物理アドレスがランタイムサービスが存在するRTRRアドレス範囲内にあるか判断するのに利用されてもよい。EFIランタイム範囲物理ベース制御レジスタ602は、EFIランタイムサービス範囲のベースアドレス及びメモリタイプを定義してもよい。少なくとも1つの実施例では、レジスタ602へのアクセスを試みる前に、IA32_MTRRCAPレジスタにおけるRTRRサポートビットがテストされる必要がありうる。RTRRサポートビットが1に設定されていない場合、通常プロテクション(GP)例外が、レジスタ602にアクセスするための試みに対して生じてもよい。レジスタ602は、例えば、少なくとも物理ベースフィールド及びタイプフィールドを含んでもよい。物理ベースフィールドは、リード/ライト（R/W）であってもよく、“XX”がプロセッサによってサポートされるアドレス可能性に依存しうるベースアドレスを設定してもよい。タイプフィールドはまた、R/Wであってもよく、RTRRメモリのキャッシュ可能性タイプを示してもよい（例えば、ライトバック（WB）メモリを表すため“6”に設定されてもよい）。

EFIランタイム範囲物理マスク制御レジスタは、共有メモリ空間アドレス範囲を決定するのに利用されるマスクを少なくとも含んでもよい。上記と同様に、IA32_MTRRCAPレジスタにおけるRTRRサポートビットは、レジスタ604にアクセスする前にテストされる必要がありうる。RTRRサポートビットが1に設定されていないと判断された場合、当該レジスタへのアクセス時にGP例外が発生する。レジスタ604は、例えば、少なくとも物理マスクフィールド及び有効フィールドを含んでもよい。物理マスクフィールドは、R/Wであってもよく、マッピングされるメモリ領域の範囲を決定するRTRRメモリ範囲マスクを設定してもよい。有効フィールドもまた、R/Wであってもよく、設定時にRTRRが有効であることを示すものであってもよい。

図7は、本開示の少なくとも1つの実施例によるファームウェア関連通知を生成及び受信するための例示的な処理を示す。処理700〜712は、デバイスにおけるプラットフォームによって実行されてもよい。処理700では、デバイスが初期化されうる。初期化中、処理702において、GUIDは、少なくとも（例えば、プラットフォームにおけるファームウェアモジュールによって）ファームウェアコンフィギュレーションテーブルにおいて構成されてもよい。処理704及び706において、プラットフォームが（例えば、プラットフォームにおいて発生するイベントに基づき）デバイスにおけるOSに通知する必要があると処理704において判定されるまで、通常処理がデバイスにおいて継続されてもよい。その後、プラットフォームは、処理708において、プラットフォーム通知テーブルに少なくとも1つのGUIDをロードし、処理710において、プラットフォーム通知テーブルのステータスフィールドにプラットフォーム通知ビットを設定してもよい。そのとき、通知（例えば、SCI）は、処理712において生成されてもよい。

処理714〜728は、デバイスにおけるOSにおいて実行されうる。処理712においてプラットフォームによって生成された通知は、処理714において、OSによって受信されうる。処理716において、OS（例えば、OSのOSMM）は、当該通知のソースを発見してもよい。通知のソースは、例えば、デバイスにおけるACPI PCCTに設定されているドアベルビットを検索することによって発見されうる。プラットフォーム通知ビットが処理710においてプラットフォームによって設定された場合、設定されたプラットフォーム通知ビットは、処理718において、プラットフォーム通知テーブルに設定されたGUIDを評価するようOSをトリガしてもよい。その後、OSは、デバイスの初期化中にファームウェアコンフィギュレーションテーブルに設定されたGUIDとプラットフォーム通知テーブルに設定された何れかのGUIDとを比較してもよい。何れかのGUIDが一致しているか否かに関する判定が、処理720において実行されてもよい。処理722において、少なくとも1つのGUIDが一致すると判定された場合、処理724において、ファームウェアコンフィギュレーションテーブルにおける少なくとも1つの一致したGUIDに対応する少なくとも1つのサービスが、OSによって呼び出されてもよい。あるいは、処理722において、GUIDの何れも一致しないと判定された場合、処理726において、getvariable（）コマンドが、プラットフォーム通知テーブルに設定されたGUIDを用いてOSによって発行されてもよく、処理728において、getvariable（）コマンドによってリターンされた何れかの値が、関連するサービスを呼び出すため利用されてもよい。

図8は、本開示の少なくとも1つの実施例によるデバイスにおける周辺トポロジ変更に関するイベント通知を生成するための例示的な処理を示す。セキュリティに関連した具体例が図4に示され、ここで、デバイスプラットフォームは、OSにおいて実行中のセキュリティリソースにデバイスにおける周辺トポロジ変更を通知可能であってもよい。ここで参照されるように、周辺トポロジ変更は、プラットフォームによって検知されうるが、OSによっては潜在的にはそうでないデバイスに関連するハードウェア、機器等の変更（例えば、追加、除去、（例えば、別のポートへの）再配置、再構成など）であってもよい。

通常のデバイス処理は、処理802において周辺トポロジ変更がデバイスにおいて行われたと判断されるまで、処理800及び802において継続されてもよい。その後、新しい周辺装置がデバイスに追加されたか否かに関する判定が、処理804において行われてもよい。処理804において、新しい周辺機器がデバイスに追加されていないと判定された場合、周辺機器がデバイスから切断されたか、あるいは、プラットフォームによって検知された他の何らかの方法で変更された変更が発生したと推定されてもよい。その後、処理806において、周辺機器の変更が許可されているか否かに関する判定が行われてもよい。変更が許可されていないと判定された場合、処理808は、ここで開示される様々な実施例に従ってOSに通知することを含むプロテクト手段が行われてもよい。処理806において、検出された周辺機器の変更が許可されていると判定された場合、処理810において、周辺機器の変更を進めることが許可されてもよい。

処理804に戻って、新しい周辺機器がデバイスに追加されたと判定された場合、処理812において、追加された周辺機器がホワイトリストに登録されているか否か（例えば、ホワイトリスト上にあるか否か）に関する判定が行われてもよい。ホワイトリストは、既知の良好又は安全な周辺機器のリストであってもよい。処理812において、追加された周辺機器がホワイトリストに載っていないという判定は、OSに通知することを含むセキュリティ対策に関係する処理808に戻ることに続いてもよい。そうでない場合、処理814において、新しい周辺機器の接続が許可されてもよい。

図7及び8は、異なる実施例による処理を示しているが、図7及び8に示される処理の全てが他の実施例について必ずしも必要とされないことが理解されるべきである。実際、本開示の他の実施例では、図7及び8に示される処理及び/又はここに説明された他の処理は、何れの図面にも具体的に示されない方法で組み合わされてもよいが、依然として本開示に完全に整合しうることが完全にここでは想定される。従って、1つの図面に正確には示されない特徴及び/又は処理に対する請求項は、本開示の範囲及び内容の範囲内であるとみなされる。

本出願及び請求項において用いられるように、“及び/又は”という用語によって結合されるアイテムのリストは、リスとされたアイテムの何れかの組み合わせを意味しうる。例えば、“A、B及び/又はC”という語句は、A、B、C、A及びB、A及びC、B及びCを意味しうる。本出願及び請求項において用いられるように、“少なくとも1つの”という用語によって結合されるアイテムのリストは、リストされた用語の何れかの組み合わせを意味することができる。例えば、“A、B又はCの少なくとも1つ”という語句は、A、B、C、A及びB、A及びC、B及びC、又はA、B及びCを意味しうる。

ここでの何れかの実施例で使用されるように、“システム”又は“モジュール”という用語は、例えば、上述の処理のいずれかを実行するよう構成されたソフトウェア、ファームウェア及び/又は回路を参照しうる。ソフトウェアは、非一時的なコンピュータ可読記憶媒体に記録されたソフトウェアパッケージ、コード、命令、命令セット及び/又はデータとして具体化されうる。ファームウェアは、メモリデバイスにおいてハードコード化（例えば不揮発性）されたコード、命令、命令セット及び/又はデータとして具現化されてもよい。ここでの何れかの実施例で使用される“回路”は、例えば、ハード配線回路、1つ以上の個別の命令処理コアを含むコンピュータプロセッサなどのプログラマブル回路、ステートマシン回路及び/又はプログラマブル回路によって実行される命令を記憶するファームウェアを単独又は何れかの組み合わせで含んでもよい。モジュールは、例えば、集積回路（IC）、システム・オン・チップ（SoC）、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバ、スマートフォンなどのより大きなシステムの一部を形成する回路としてまとめて又は個別に具体化されてもよい。

ここで説明される処理のいずれも、1つ以上のプロセッサによって実行されたとき、当該方法を実行する命令を個々に又は組み合わせて格納した1つ以上の記憶媒体（例えば、非一時的記憶媒体）を含むシステムにおいて実現されうる。ここで、プロセッサは、例えば、サーバCPU、モバイルデバイスCPU及び/又は他のプログラマブル回路を含みうる。また、ここで説明される処理は、複数の異なる物理的位置における処理構造など、複数の物理デバイスにわたって分散されてもよいことが意図される。記憶媒体は、例えば、ハードディスク、フロッピーディスク、光ディスク、CD-ROM、CD-RW及び光磁気ディスクを含む何れかのタイプのディスク、ROM、ダイナミック及びスタティックRAMなどのRAM、EPROM、EEPROM、フラッシュメモリ、ソリッドステートディスク（SSD）、埋め込みマルチメディアカード（eMMC）、セキュアデジタル入出力（SDIO）カード、磁気若しくは光カードなどの半導体デバイス、又は電子命令を格納するのに適した何れかのタイプの媒体などの何れかのタイプの有形媒体を含んでもよい。他の実施例は、プログラム可能な制御デバイスによって実行されるソフトウェアモジュールとして実現されてもよい。

従って、本開示は、ファームウェア関連イベント通知に関する。デバイスは、プラットフォーム上で動作するよう構成されたオペレーティングシステム（OS）を備えてもよい。デバイスの初期化中、プラットフォームにおけるファームウェアモジュールは、少なくとも1つのグローバルに一意的な識別子（GUID）をファームウェアコンフィギュレーションテーブルにロードしてもよい。プラットフォームがOSに通知すると、ファームウェアモジュールは、少なくとも1つのGUIDをプラットフォーム通知テーブルにロードし、プラットフォーム通知テーブルのステータスフィールドにプラットフォーム通知ビットを設定してもよい。当該通知を検出すると、OS管理モジュールは、プラットフォーム通知テーブルをクエリすることによって通知のソースを確定してもよい。プラットフォーム通知ビットは、OS管理モジュールにプラットフォーム通知テーブルとファームウェアコンフィギュレーションテーブルとにおけるGUIDを比較させてもよい。サービスは、何れか一致したGUIDに基づき呼び出されてもよい。一致するGUIDがない場合、サービスはデバイスにおけるファームウェア変数に基づき呼び出されてもよい。

以下の具体例は、更なる実施例に関する。本開示の以下の具体例は、デバイス、方法、実行時に当該方法に基づく処理をマシンに実行させる命令を記憶するための少なくとも1つのマシン可読媒体、当該方法に基づく処理を実行する手段及び/又はファームウェア関連イベント通知のためのシステムなどの主題を含んでもよい。

具体例１によると、ファームウェア関連イベント通知を生成するデバイスが提供される。当該デバイスは、共有メモリ空間を少なくとも含むメモリモジュールと、メッセージングインタフェースの少なくとも一部を共有メモリ空間にロードし、メッセージングインタフェースにデバイスにおけるオペレーティングシステムに対する通知を生成させるファームウェアモジュールと、オペレーティングシステムから受信した命令に少なくとも基づきデバイスにおいて処理を実行する処理モジュールであって、オペレーティングシステムはメッセージングインタフェースによって提供された通知に少なくとも反応するオペレーティングシステム管理モジュールを含む、処理モジュールとを有する。

具体例２は、具体例１の要素を含んでもよく、デバイスの初期化中、ファームウェアモジュールは、少なくとも1つのグローバルに一意的な識別子及び対応するサービス識別子のエントリをファームウェアコンフィギュレーションテーブルにロードするか、あるいは、少なくとも1つのファームウェア変数を生成することの少なくとも一方を行う。

具体例３は、具体例２の要素を含んでもよく、ファームウェアコンフィギュレーションテーブルは、UEFI(Unified Extensible Firmware Interface)規格に基づく。

具体例４は、具体例２〜３の何れかの要素を含んでもよく、ファームウェアモジュールは、通知が生成される前に、少なくとも1つのグローバルに一意的な識別子を共有メモリ空間におけるプラットフォーム通知テーブルにロードする。

具体例５は、具体例４の要素を含んでもよく、プラットフォーム通知テーブルは、ACPI（Advanced Configuration and Power Interface）規格に基づく。

具体例６は、具体例４〜５の何れかの要素を含んでもよく、通知は、システム制御インタラプト（SCI）である。

具体例７は、具体例４〜６の何れかの要素を含んでもよく、プラットフォーム通知テーブルは、物理ベース制御レジスタ又は物理マスク制御レジスタの少なくとも1つによってプロテクトされる。

具体例８は、具体例７の要素を含んでもよく、物理ベース制御レジスタは、ファームウェアモジュールのランタイム部分に対する未承認の書き込みをプロテクトする。

具体例９は、具体例７〜８の何れかの要素を含んでもよく、物理マスク制御レジスタは、共有メモリ空間のアドレス範囲を決定する。

具体例１０は、具体例４〜９の何れかの要素を含んでもよく、ファームウェアモジュールは更に、プラットフォーム通知テーブルのステータスフィールドに少なくとも1つのプラットフォーム通知ビットを設定する。

具体例１１は、具体例１０の要素を含んでもよく、オペレーティングシステム管理モジュールは、処理モジュールに少なくともプラットフォーム通知テーブルをクエリすることによって、通知のソースを発見させる。

具体例１２は、具体例１１の要素を含んでもよく、オペレーティングシステム管理モジュールは、ACPIプラットフォーム通信チャネル（PCC）テーブルに設定されたドアベルビットをクエリすることによって、通知のソースを発見する。

具体例１３は、具体例１０〜１２の何れかの要素を含んでもよく、プラットフォーム通知ビットがプラットフォーム通知テーブルにおいて設定されていると判定したことに応答して、オペレーティングシステム管理モジュールは、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がファームウェアコンフィギュレーションテーブルにロードされた何れかグローバルに一意的な識別子と同じであるか処理モジュールに判定させる。

具体例１４は、具体例１３の要素を含んでもよく、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がファームウェアコンフィギュレーションテーブルにロードされた何れのグローバルに一意的な識別子とも同じでないと判定したことに応答して、オペレーティングシステム管理モジュールは、処理モジュールにファームウェアコンフィギュレーションテーブルからファームウェア変数を要求させる。

具体例１５は、具体例１４の要素を含んでもよく、オペレーティングシステム管理モジュールは、ファームウェアコンフィギュレーションテーブルにおけるグローバルに一意的な識別子に一致すると判定されたプラットフォーム通知テーブルにおけるグローバルに一意的な識別子に対応するサービス識別子か、あるいは、一致するグローバルに一意的な識別子がないと判定された場合、リターンされたファームウェア変数に基づき、オペレーティングシステムにおける少なくとも1つのサービスを処理モジュールに呼び出させる。

具体例１６は、具体例１〜１５の何れかの要素を含んでもよく、通知は、デバイスにおいて検出された周辺トポロジ変更に基づき生成される。

具体例１７は、具体例１６の要素を含んでもよく、周辺機器の変更が許可されないとき、あるいは、非ホワイトリスト周辺機器がデバイスに追加されたとき、通知が生成される。

具体例１８は、具体例１〜１７の何れかの要素を含んでもよく、ファームウェアモジュールの少なくともランタイム要素が、Authenticode Dynamic Linked Libraryを用いて署名することによってプロテクトされる。

具体例１９は、具体例１〜１８の何れかの要素を含んでもよく、ファームウェアモジュールの少なくともランタイム要素は、信頼される実行環境内で実行されるデバイスセキュリティの一部によって実行されるチャレンジ/レスポンスインタラクションによってプロテクトされる。

具体例２０は、具体例１９の要素を含んでもよく、信頼される実行環境は、Secure Guard Extensionを用いて確立される。

具体例２１によると、ファームウェア関連通知を生成する方法が提供される。当該方法は、デバイスにおいてファームウェアコンフィギュレーションテーブルを設定し、デバイスにおけるプラットフォームからの通知がデバイスにおけるオペレーティングシステムに対して生成される必要があると判定し、デバイスにおいてプラットフォーム通知テーブルを設定し、通知を生成することを含んでもよい。

具体例２２は、具体例２１の要素を含んでもよく、ファームウェアコンフィギュレーションテーブルを設定することは、少なくとも1つのグローバルに一意的な識別子及び対応するサービス識別子のエントリをファームウェアコンフィギュレーションテーブルにロードするか、あるいは、少なくとも1つのファームウェア変数を生成することの少なくとも一方を行うことを含む。

具体例２３は、具体例２１〜２２の何れかの要素を含んでもよく、デバイスにおいてプラットフォーム通知テーブルを設定することは、少なくとも1つのグローバルに一意的な識別子をプラットフォーム通知テーブルにロードし、ステータスフィールドに少なくとも1つのプラットフォーム通知ビットを設定することを含む。

具体例２４は、具体例２１〜２３の何れかの要素を含んでもよく、デバイスにおける周辺トポロジ変更を検出したことに基づき、通知が必要とされると判定することを更に含む。

具体例２５は、具体例２４の要素を含んでもよく、周辺機器の変更が許可されないとき、あるいは、非ホワイトリスト周辺機器がデバイスに追加されたとき、通知を生成することを更に含んでもよい。

具体例２６は、具体例２１〜２５の何れかの要素を含んでもよく、物理ベース制御レジスタ又は物理マスク制御レジスタの少なくとも1つによってプラットフォーム通知テーブルを少なくともプロテクトすることを更に含んでもよい。

具体例２７によると、ファームウェア関連通知を受信する方法が提供される。当該方法は、デバイスにおけるオペレーティングシステムにおいて通知を受信し、デバイスにおけるプラットフォーム通知テーブルを少なくともクエリすることに基づき、通知のソースを発見し、プラットフォーム通知ビットがプラットフォーム通知テーブルのステータスフィールドに設定されているか判定することを含んでもよい。

具体例２８は、具体例２７の要素を含んでもよく、通知のソースを発見することは、ACPIプラットフォーム通信チャネル（PCC）テーブルに設定されたドアベルビットをクエリすることを含む。

具体例２９は、具体例２７〜２８の何れかの要素を含んでもよく、プラットフォームビットが設定されていることに応答して、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がデバイスにおけるファームウェアコンフィギュレーションテーブルにロードされる何れかのグローバルに一意的な識別子と同じであるか判定し、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がファームウェアコンフィギュレーションテーブルにロードされる何れのグローバルに一意的な識別子とも同じでないと判定したことに応答して、ファームウェア変数を要求し、ファームウェアコンフィギュレーションテーブルにおけるグローバルに一意的な識別子に一致すると判定されたプラットフォーム通知テーブルにおけるグローバルに一意的な識別子に対応するサービス識別子又はリターンされたファームウェア変数に基づきオペレーティングシステムにおける少なくとも1つのサービスを呼び出すことを更に含んでもよい。

具体例３０によると、少なくともデバイスを含むシステムであって、上記具体例２１〜２９の何れかの方法を実行するよう構成されるシステムが提供される。

具体例３１によると、上記具体例２１〜２９の何れかの方法を実行するよう構成されるチップセットが提供される。

具体例３２によると、コンピューティングデバイス上で実行されることに応答して、上記具体例２１〜２９の何れかによる方法をコンピューティングデバイスに実行させる複数の命令を有する少なくとも1つのマシン可読媒体が提供される。

具体例３３によると、ファームウェア関連イベント通知のための構成されたデバイスであって、上記具体例２１〜２９の何れかの方法を実行するよう構成されるデバイスが提供される。

具体例３４によると、ファームウェア関連通知を生成するシステムが提供される。当該システムは、デバイスにおいてファームウェアコンフィギュレーションテーブルを設定する手段、デバイスにおけるプラットフォームからの通知がデバイスにおけるオペレーティングシステムに対して生成される必要があると判定する手段、デバイスにおいてプラットフォーム通知テーブルを設定する手段、及び通知を生成する手段を含んでもよい。

具体例３５は、具体例３４の要素を含んでもよく、ファームウェアコンフィギュレーションテーブルを設定する手段は、少なくとも1つのグローバルに一意的な識別子及び対応するサービス識別子のエントリをファームウェアコンフィギュレーションテーブルにロードするか、あるいは、少なくとも1つのファームウェア変数を生成することの少なくとも一方を行う手段を含む。

具体例３６は、具体例３４〜３５の何れかの要素を含んでもよく、デバイスにおいてプラットフォーム通知テーブルを設定する手段は、少なくとも1つのグローバルに一意的な識別子をプラットフォーム通知テーブルにロードする手段、及びステータスフィールドに少なくとも1つのプラットフォーム通知ビットを設定する手段を含む。

具体例３７は、具体例３４〜３６の何れかの要素を含んでもよく、デバイスにおける周辺トポロジ変更を検出したことに基づき、通知が必要とされると判定する手段を更に含んでもよい。

具体例３８は、具体例３７の要素を含んでもよく、周辺機器の変更が許可されないとき、あるいは、非ホワイトリスト周辺機器がデバイスに追加されたとき、通知を生成する手段を更に含んでもよい。

具体例３９は、具体例３４〜３８の何れかの要素を含んでもよく、物理ベース制御レジスタ又は物理マスク制御レジスタの少なくとも1つによってプラットフォーム通知テーブルを少なくともプロテクトする手段を更に含んでもよい。

具体例４０によると、ファームウェア関連通知を受信するシステムが提供される。当該システムは、デバイスにおけるオペレーティングシステムにおいて通知を受信する手段、デバイスにおけるプラットフォーム通知テーブルを少なくともクエリすることに基づき、通知のソースを発見する手段、及びプラットフォーム通知ビットがプラットフォーム通知テーブルのステータスフィールドに設定されているか判定する手段を含んでもよい。

具体例４１は、具体例４０の要素を含んでもよく、通知のソースを発見する手段は、ACPIプラットフォーム通信チャネル（PCC）テーブルに設定されたドアベルビットをクエリすることを含む。

具体例４２は、具体例４０〜４１の何れかの要素を含んでもよく、プラットフォームビットが設定されていることに応答して、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がデバイスにおけるファームウェアコンフィギュレーションテーブルにロードされる何れかのグローバルに一意的な識別子と同じであるか判定する手段、プラットフォーム通知テーブルにおける少なくとも1つのグローバルに一意的な識別子がファームウェアコンフィギュレーションテーブルにロードされる何れのグローバルに一意的な識別子とも同じでないと判定したことに応答して、ファームウェア変数を要求する手段、及びファームウェアコンフィギュレーションテーブルにおけるグローバルに一意的な識別子に一致すると判定されたプラットフォーム通知テーブルにおけるグローバルに一意的な識別子に対応するサービス識別子又はリターンされたファームウェア変数に基づきオペレーティングシステムにおける少なくとも1つのサービスを呼び出す手段を更に含んでもよい。

ここに用いられた用語及び表現は、限定でなく説明の用語として用いられ、そのような用語及び表現の利用において、図示及び説明された特徴（又はその一部）の何れの均等も排除する意図はなく、各種修正が請求項の範囲内で可能であることが認識される。従って、請求項はそのような全ての均等をカバーすることが意図される。

Claims (10)

1. ファームウェア関連イベント通知を生成するデバイスであって、
   共有メモリ空間を少なくとも含むメモリモジュールと、
   メッセージングインタフェースの少なくとも一部を前記共有メモリ空間にロードし、前記メッセージングインタフェースに前記デバイスにおけるオペレーティングシステムに対する通知を生成させるファームウェアモジュールと、
   前記オペレーティングシステムから受信した命令に少なくとも基づき前記デバイスにおいて処理を実行する処理モジュールであって、前記オペレーティングシステムは前記メッセージングインタフェースによって提供された前記通知に少なくとも反応するオペレーティングシステム管理モジュールを含む、処理モジュールと、
   を有するデバイス。
2. 前記デバイスの初期化中、前記ファームウェアモジュールは、少なくとも1つのグローバルに一意的な識別子及び対応するサービス識別子のエントリをファームウェアコンフィギュレーションテーブルにロードするか、あるいは、少なくとも1つのファームウェア変数を生成することの少なくとも一方を行う、請求項１記載のデバイス。
3. 前記ファームウェアコンフィギュレーションテーブルは、UEFI(Unified Extensible Firmware Interface)規格に基づく、請求項２記載のデバイス。
4. 前記ファームウェアモジュールは、通知が生成される前に、少なくとも1つのグローバルに一意的な識別子を前記共有メモリ空間におけるプラットフォーム通知テーブルにロードする、請求項２記載のデバイス。
5. 前記プラットフォーム通知テーブルは、ACPI（Advanced Configuration and Power Interface）規格に基づく、請求項４記載のデバイス。
6. 前記通知は、システム制御インタラプト（SCI）である、請求項４記載のデバイス。
7. 前記プラットフォーム通知テーブルは、物理ベース制御レジスタ又は物理マスク制御レジスタの少なくとも1つによってプロテクトされる、請求項４記載のデバイス。
8. 前記ファームウェアモジュールは更に、前記プラットフォーム通知テーブルのステータスフィールドに少なくとも1つのプラットフォーム通知ビットを設定する、請求項４記載のデバイス。
9. 前記オペレーティングシステム管理モジュールは、前記処理モジュールに少なくとも前記プラットフォーム通知テーブルをクエリすることによって、前記通知のソースを発見させる、請求項８記載のデバイス。
10. 前記通知は、前記デバイスにおいて検出された周辺トポロジ変更に基づき生成される、請求項１記載のデバイス。

Images