(57)【要約】      （修正有）【課題】自動化されたモジュールのセキュアな起動ファームウェアの更新のための方法を提供する。【解決手段】システムのセキュアなパーティションで、更新された起動ファームウェアコードモジュールを受信し、１つの元の起動ファームウェアコードモジュールのみを、更新された起動ファームウェアコードモジュールで自動的に置き換え、次にシステムが起動されたときにユーザの介入なしにシステムの複数の起動ファームウェアコードモジュールにより、更新された起動ファームウェアコードモジュールを自動的に実行する。ファームウェアボリュームの更新パーティションに、更新された起動ファームウェアコードモジュールを書き込み、ファームウェアボリュームの更新パーティションは、システムの起動時に複数の起動ファームウェアコードモジュールを含むファームウェアボリュームの別のパーティションとともに読み出される。【選択図】図１
2011118873.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ実装される方法であって、
システムのセキュアなパーティションで、前記システムの複数の起動ファームウェアコードモジュールの１つの元の起動ファームウェアコードモジュールの置き換えとして、更新された起動ファームウェアコードモジュールを受信する段階と、
前記１つの元の起動ファームウェアコードモジュールのみを、前記更新された起動ファームウェアコードモジュールで自動的に置き換える段階と、
次に前記システムが起動されたときにユーザの介入を受けずに、前記システムの前記複数の起動ファームウェアコードモジュールにより、前記更新された起動ファームウェアコードモジュールを自動的に実行する段階と
を備える方法。
【請求項２】
ファームウェアボリュームの更新パーティションに前記更新された起動ファームウェアコードモジュールを書き込む段階をさらに備え、
前記ファームウェアボリュームの前記更新パーティションは、前記システムの起動時に前記複数の起動ファームウェアコードモジュールを含む前記ファームウェアボリュームの別のパーティションとともに読み出される請求項１に記載の方法。
【請求項３】
前記ファームウェアボリュームの前記更新パーティションに前記更新された起動ファームウェアモジュールを書き込む段階の前に、前記更新された起動ファームウェアモジュールの整合性を認証する段階をさらに備える請求項２に記載の方法。
【請求項４】
前記更新された起動ファームウェアモジュールは、前記セキュアなパーティションに連結されたバンド外通信チャネルを介してサーバにより提供される請求項１に記載の方法。
【請求項５】
前記更新された起動ファームウェアモジュールを受信する段階の前に前記サーバの整合性を認証する段階をさらに備える請求項４に記載の方法。
【請求項６】
前記更新された起動ファームウェアモジュールのロード中に問題が生じた場合、前記１つの元の起動ファームウェアコードモジュールをロードさせる段階をさらに備える請求項１に記載の方法。
【請求項７】
前記システムの起動後に、前記更新された起動ファームウェアコードモジュールのインストールステータスを、前記更新された起動ファームウェアコードモジュールの送信元であるサーバに提供する段階をさらに備える請求項１に記載の方法。
【請求項８】
システムであって、
ホストオペレーティングシステムと前記システムの複数の起動ファームウェアコードモジュールとを実行する少なくとも１つのプロセッサと、
前記プロセッサに連結され、前記ホストオペレーティングシステムから隔離されたセキュアなパーティションと、
前記セキュアなパーティションで、前記システムの複数の起動ファームウェアコードモジュールの１つの元の起動ファームウェアコードモジュールの置き換えとして、更新された起動ファームウェアコードモジュールを受信する手段と、
前記１つの元の起動ファームウェアコードモジュールのみを、前記更新された起動ファームウェアコードモジュールで自動的に置き換える手段と、
次に前記システムが起動されたときにユーザの介入を受けずに、前記システムの前記複数の起動ファームウェアコードモジュールにより、前記更新された起動ファームウェアコードモジュールを自動的に実行する手段と
を備えるシステム。
【請求項９】
ファームウェアボリュームの更新パーティションに前記更新された起動ファームウェアコードモジュールを書き込む手段をさらに備え、
前記ファームウェアボリュームの前記更新パーティションは、前記システムの起動時に前記複数の起動ファームウェアコードモジュールを含む前記ファームウェアボリュームの別のパーティションとともに読み出される請求項８に記載のシステム。
【請求項１０】
前記ファームウェアボリュームの前記更新パーティションに前記更新された起動ファームウェアモジュールを書き込む前に、前記更新された起動ファームウェアモジュールの整合性を認証する手段をさらに備える請求項９に記載のシステム。
【請求項１１】
前記更新された起動ファームウェアモジュールは、前記セキュアなパーティションに連結されたバンド外通信チャネルを介してサーバにより提供される請求項８に記載のシステム。
【請求項１２】
前記更新された起動ファームウェアモジュールの受信前に前記サーバの整合性を認証する手段をさらに備える請求項１１に記載のシステム。
【請求項１３】
前記更新された起動ファームウェアモジュールのロード中に問題が生じた場合、前記１つの元の起動ファームウェアコードモジュールをロードさせる手段をさらに備える請求項８に記載のシステム。
【請求項１４】
前記システムの起動後に、前記更新された起動ファームウェアコードモジュールのインストールステータスを、前記更新された起動ファームウェアコードモジュールの送信元であるサーバに提供する手段をさらに備える請求項８に記載のシステム。
【請求項１５】
コンピュータ可読記憶媒体と、
前記コンピュータ可読記憶媒体内の命令とを備え、
前記命令は、処理システムで実行されると、前記処理システムに請求項１から請求項７のいずれか一項に記載の方法を実行させるコンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
＜著作権に関する注意書＞
ここには、著作権保護の対象材料が含まれている。著作権保持者は、本特許の開示の特許商標庁におけるファイルまたは記録の複写には何人に対しても異議を唱えないが、それ以外の全ての著作権を保留する。
【０００２】
本開示は概して、コンピュータシステムにおけるＢＩＯＳおよび起動ファームウェアコードの維持に係る。
【背景技術】
【０００３】
元来はＩＢＭ  ＰＣに互換性を有するコンピュータに向けて開発されたものではあるが、基本入出力システム（ＢＩＯＳ）（システムＢＩＯＳとも称される）は、事実上、ファームウェアインタフェースを定義する規格である。ＢＩＯＳは、電源投入されるとＰＣが実行する最初のコードとして設計される起動ファームウェアである。当初想定されていたＢＩＯＳの機能は、ビデオ表示カード、ハードディスク、およびフロッピー（登録商標）ディスク、およびその他のハードウェア等のシステムデバイスを識別、テスト、および初期化するという機能である。これによりマシンが既知の状態となり、互換性のある媒体上のオペレーティングシステム等のソフトウェアをロード、実行することができ、ひいてはＰＣの任意の制御を行うことができる。この処理は起動（bootstrappingを短縮してbooting、booting up等と称される）として知られている。
【０００４】
ＢＩＯＳプログラムは、キーボード、テキスト表示機能等の周辺機器を作動させ制御するべく呼び出すことのできる基本入出力機能の小さいライブラリを提供する。システムに電源投入がなされると、ＢＩＯＳはシステム構成設定をチェックして、ハードウェアコンポーネントとオペレーティングシステムとの間でトランスレータとして作動するプログラムをメモリにロードする。例えば、ユーザがキーボード上のキーを押下すると、信号を受けたキーボード割り込みハンドラはその旨をプロセッサに伝え、オペレーティングシステムに渡す。
【０００５】
ＢＩＯＳは、まだプロセッサが１６ビットのプロセッサモードで機能しており、アドレス可能なメモリが１メガバイトに制限され、コードがＩＢＭ  ＰＣ  ＡＴハードウェアの欠陥を反映していた頃のＩＢＭ  ＰＣ用に開発された。後に開発された３２ビットプロセッサ用オペレーティングシステムはＩ／Ｏを処理するデバイスドライバを含むようになり、ＢＩＯＳが提供する１６ビットのランタイムインタフェース呼び出しに依存しなくなった。これらデバイスドライバの多くは、プラットフォームファームウェアが提供し、オペレーティングシステムのロード前のＢＩＯＳ初期化中にメモリにロードされる。ＥＦＩ（Extensible Firmware Interface）は、オペレーティングシステムとプラットフォームファームウェアとの間のソフトウェアインタフェースを定義する仕様である。ＥＦＩは、様々なデバイス、バス、ブロック、およびファイルのサービス、並びに、日付、時間、およびＮＶＲＡＭサービス等のランタイムサービス上のテキストおよびグラフィックコンソールサポートを含む起動サービスを定義している。ＥＦＩ仕様のさらなる情報については、ＵＲＬ（developer-intel-com/technology/efi/main_specification.htm）を参照されたい（本明細書ではＵＲＬを接頭の「http://」を省き、「.」という文字を「-」で置き換えて記すことで、本書類からのアクティブなハイパーリンクを回避するようにしている）。
【図面の簡単な説明】
【０００６】
【図１】本発明の一実施形態における自動化されたモジュール型起動ファームウェア更新を可能とするよう構成されたシステムのブロック図である。
【図２】本発明の一実施形態における自動化されたモジュール型起動ファームウェア更新を可能とする図１のシステムのさらなる詳細を示す。
【図３】本発明の一実施形態における自動化されたモジュール型起動ファームウェア更新を行う、起動ファームウェアモジュール更新マネージャと企業起動ファームウェアモジュール更新サービスとの間の相互作用を示すフロー図である。
【図４】本発明の一実施形態のコンポーネントが動作する起動シーケンスの各段階を示す。
【図５】本発明の一実施形態におけるシステムを起動するときのモジュール型起動ファームウェア更新を行う方法のフローチャートである。
【図６】本発明の一実施形態において、実自動化されたモジュール型起動ファームウェア更新が実行された後のシステムの起動を示すフロー図である。
【図７】本発明の一実施形態における起動ファームウェアモジュール更新マネージャを実装する仮想マシン環境を示す。
【発明を実施するための形態】
【０００７】
本発明の実施形態は、モジュール型起動ファームウェア更新を実行する方法、装置、システム、およびコンピュータプログラムプロダクトを提供しうる。ＢＩＯＳおよびプラットフォームファームウェア更新は従来、ＢＩＯＳ／起動ファームウェアコードモジュールのモノリシックな画像を提供して、ローカルユーザに対してシステムを再起動させ、ＢＩＯＳ／起動ファームウェア更新をインストールさせることにより行われてきた。
【０００８】
一実施形態では、方法は、更新起動ファームウェアコードモジュールを受信して、システムの複数の起動ファームウェアコードモジュールのうちのある１つの起動ファームウェアコードモジュールを置き換えて、システムの起動時に、該１つの起動ファームウェアコードモジュールではなくて、自動的に更新された起動ファームウェアコードモジュールのほうをロードすることを含む。この更新された起動ファームウェアコードモジュールは、システムの起動時に、該１つの起動ファームウェアコードモジュールのみを置き換え、システムの起動ファームウェアコードモジュール全部を置き換えることはしない。
【０００９】
更新された起動ファームウェアコードモジュールを自動的にロードすることは、システムのユータの動作なしに行うことができる。一実施形態では、方法は、ファームウェアボリュームの更新パーティションに、更新された起動ファームウェアコードモジュールを書き込むことを含み、ファームウェアボリュームの更新パーティションは、システムの起動時に起動ファームウェアコードモジュールを含むファームウェアボリュームの別のパーティションとともに読み出される。方法は、更新された起動ファームウェアモジュールをファームウェアボリュームの更新パーティションに書き込む前に、更新された起動ファームウェアモジュールの整合性を確かめることを含む。
【００１０】
一実施形態では、更新された起動ファームウェアモジュールは、マイクロプロセッサに連結されたバンド外通信チャネルを介してサーバにより提供される。方法はさらに、更新された起動ファームウェアモジュールの受信前に、サーバの整合性を認証することを含んでよい。更新された起動ファームウェアモジュールのロード中に問題が生じた場合、方法は、元の起動ファームウェアモジュールをロードさせることを含んでよい。一実施形態では、方法はさらに、システムの起動後に、更新された起動ファームウェアモジュールのインストールステータスを、該更新された起動ファームウェアモジュールの送信元であるサーバに提供することを含む。
【００１１】
本発明は、従来のＢＩＯＳ／プラットフォームファームウェアのモノリシックな画像の更新処理を向上させ、ＢＩＯＳおよびプラットフォームファームウェアのモジュラー型のセキュアな更新を行う。本発明では、特定のＢＩＯＳ／プラットフォームファームウェアコードモジュール／ドライバまたはアプリケーションに対して更新を行うことができる。プラットフォームファームウェアが益々高度になり、セキュリティフィーチャ等の重要な機能を提供するようになると、ＢＩＯＳおよびプラットフォームファームウェアの欠陥はこのようにして急速に訂正できるようになるので、元の機器製造業者が、システムのフラッシュメモリのＢＩＯＳ／プラットフォームファームウェア領域全体に対して新たなモノリシックな画像の提供を必要とせず、企業管理サーバによる提供が可能となる。
【００１２】
本発明の明細書における「一実施形態（one embodiment）、（an embodiment）」といった言い回しは、ある実施形態で記載される特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを示す。従って明細書の随所に記載されている「一実施形態では（in one embodiment）」「一実施形態において（according to one embodiment）」といった表現は、必ずしも全てが同じ実施形態のことではない。
【００１３】
説明をし易くするべく、特定の構成および詳細を示すことで本発明の完全な理解を促している箇所がある。しかし本発明の実施形態をここに記載されている特定の詳細なしに実施することができることは当業者には明らかである。さらに、公知の特徴は省略または簡略化することで、本発明を曖昧にしないようにしている箇所もある。様々な例を本記載において提供する。これらはあくまで本発明の特定の実施形態を記載したものである。本発明の範囲はこれらの例に限定はされない。
【００１４】
一実施形態においては、企業プラットフォーム管理サービスから起動ファームウェアコードモジュール更新を受信するための隔離且つ制御された環境を提供するセキュアなパーティション内に、モジュール型起動ファームウェア更新サービスを提供する。このセキュアなパーティションは、システムの起動ファームウェアコードの更新が、認証当局発行のものであることを認証する。
【００１５】
起動ファームウェアモジュール更新サービスの、隔離されセキュアな環境は、完全に分割されたハードウェアパーティション（例えば、インテル（登録商標）コーポレーションのＭＥ（Manageability Engine）、ＡＭＴ（Active Management Technologies）、ＰＲＬ（Platform Resource Layer）および／または他の互換性を有する技術または類似した技術）および／または仮想化パーティション（例えば、インテル（登録商標）コーポレーションのＶＴスキーム（Virtualization Technology scheme））を含む様々な異なる種類のパーティションを含んでよい。当業者であれば、仮想化されたホストもＭＥ、ＡＭＴ、およびＰＲＬ技術の実装に利用可能であることを理解するであろう（図７を参照して以下で詳述する）。
【００１６】
図１は、本発明の一実施形態におけるモジュール型起動ファームウェア更新を可能とするよう構成されたシステムのブロック図である。プラットフォーム１００（ホストコンピュータシステムに相当する）は、デスクトップ管理インタフェース（ＤＭＩ）１１１経由でチップセット１２０に接続されたプロセッサ１１０を含む。プロセッサ１１０は、プラットフォーム１００に処理電力を供給し、シングルコアまたはマルチコアプロセッサであってよく、プラットフォーム１００に複数のプロセッサが含まれてよい。プロセッサ１１０は、１以上のシステムバス、通信経路または媒体（不図示）を介してプラットフォーム１００の他のコンポーネントと接続されてよい。
【００１７】
チップセット１２０は、ＭＥ１３０を含み、ＭＥ１３０はホストプロセッサ１１０とは独立して動作する埋め込みマイクロプロセッサとして実装されて、プラットフォーム１００の構成および動作を管理する。一実施形態では、プロセッサ１１０がホストオペレーティングシステム（不図示）の直下で動作し、一方、ＭＥ１３０は、ホストオペレーティングシステムがアクセスすることのできないセキュアで隔離された環境を提供する。一実施形態では、ＭＥ１３０はユーザを認証し、周辺デバイスへのアクセスを制御し、プラットフォーム１００の記憶デバイスに格納されているデータを保護する暗号鍵を管理し、ネットワークコントローラ１６０を介して企業サービス１７０へのインタフェースを提供する。ＭＥ１３０は、企業サービス１７０を利用して、本発明の一実施形態における起動ファームウェアモジュール更新のサービスの提供を含むプラットローム１００等のプラットフォームの構成および管理の企業全体のポリシーとの一貫性を維持する。起動ファームウェアモジュール更新マネージャは、ＭＥ１３０により実行されるファームウェアとして実装することができる。
【００１８】
ＭＥ１３０と企業サービス１７０との間の通信は、バンド外通信チャネル１７１を介して行われる。一実施形態では、バンド外通信チャネル１７１は、ホストシステム上のＭＥ１３０と、ホストシステムを管理する企業サービス１７０との間のセキュアな通信チャネルである。プラットフォーム１００と企業サービス１７０との間でセキュアな通信を行わせる暗号／復号鍵が、チップセット１２０およびＭＥ１３０の製造中に図１のフラッシュメモリ１９０に格納されてよい。
【００１９】
図１に示す実施形態では、ＭＥ１３０が、ＭＥＣＩ（Manageability Engine Controller Interface）１３１を介してマイクロコントローラ１４０に連結される。一実施形態では、マイクロコントローラ１４０は、格納コマンド復号化およびその他の加速動作を行う汎用コントローラである。示されている実施形態では、ＭＥ１３０がマイクロコントローラ１４０の振る舞いを制御し、マイクロコントローラ１４０が今度は格納コントローラ１５０の振る舞いを制御する。マイクロコントローラ１４０は、格納コントローラ１５０のドライバ、および、ディスク暗号機能に関するロジックを含む。格納コントローラ１５０は、記憶デバイス１５２等の記憶デバイス用のコントローラであり、マイクロコントローラ１４０およびＭＥ１３０に、記憶デバイス１５２に格納されているデータへのアクセスを可能とする。
【００２０】
プラットフォーム１００はさらに、ＤＲＡＭ１１２、チップセット１２０内のＳＲＡＭ１２２、フラッシュメモリ１９０、および、格納コントローラ１５０がアクセス可能な記憶デバイス１５２等のメモリデバイスを含む。これらメモリデバイスは、ＲＡＭおよびＲＯＭを含んでよい。本開示においては、ＲＯＭという用語は、通常、ＥＰＲＯＭ、ＥＥＰＲＯＭ（登録商標）、フラッシュＲＯＭ、フラッシュメモリ等の不揮発性メモリデバイスを意味する。記憶デバイス１５２は、集積ドライブエレクトロニクス（ＩＤＥ）ハードドライブ等の大容量記憶デバイス、および／または、フロッピー（登録商標）ディスク、光記憶デバイス、テープ、フラッシュメモリ、メモリスティック、デジタルビデオディスク、生物学的記憶装置等の他のデバイスまたは媒体を含んでよい。
【００２１】
フラッシュメモリ１９０は、フラッシュインタフェース１９１を解してチップセット１２０からアクセス可能である。記憶デバイス１５２および／またはメモリデバイスＤＲＡＭ１１２、ＳＲＡＭ１２２、およびフラッシュメモリ１９０に格納されるデータは暗号化されていてよい。
【００２２】
フラッシュメモリ１９０は、プラットフォーム１００を初期化するのに利用されるファームウェアを含む。この初期化ファームウェアは、システムコンポーネントハードウェア（例えばビデオ表示カードおよびハードディスク）、および、ＭＥ１３０を含む幾らかのその他のハードウェアデバイスを識別および初期化するＢＩＯＳファームウェア１９２を含む。ＢＩＯＳファームウェア１９２は、プラットフォーム１００のシステムコンポーネントハードウェアを準備して、既知の低容量状態で動作させ、オペレーティングシステムを含む様々な媒体に格納されている他のソフトウェアプログラムがロード、実行、およびプラットフォーム１００の制御下におかれるようにする。ＢＩＯＳファームウェア１９２は、起動処理中にＭＥ１３０の初期構成をイネーブルするＢＩＯＳ／ＭＥ通信モジュール１９３を含む。一実施形態では、ＭＥ１３０はＢＩＯＳ／ＭＥ通信モジュール１９３に登録を行って、オペレーティングシステムがプラットフォーム１００にロードされる直前に通知を受け取るようにすることができる。この通知により、ＭＥ１３０は、一定の命令を実行して、オペレーティングシステムのロードに備えることができる。
【００２３】
フラッシュメモリ１９０はさらに、ネットワークコントローラ１６０を構成するネットワークコントローラファームウェア１９５、および、チップセット１２０を構成するチップセットファームウェア１９６を含む。フラッシュメモリ１９０はさらにデータ領域１９８を含む。一実施形態では、データ領域１９８は暗号化されており、ＭＥ１３０によってのみ読み出し可能である。ＭＥ１３０がＢＩＯＳ／起動ファームウェアモジュール更新管理サービスの提供に利用する情報は、フラッシュメモリ１９０のデータ領域１９８に、または記憶デバイス１５２上に格納されていてよい。
【００２４】
従来、プラットフォームを初期化して、ＢＩＯＳを開始させ、システムにオペレーティングシステムロードの準備をさせる全てのファームウェアは、フラッシュメモリ１９０等の不揮発性記憶装置にロードされるモノリシックな画像として提供されてきた。例えば、フラッシュメモリ１９０は、製造業者から、ＢＩＯＳファームウェア１９２のモノリシックな画像全体を含むよう準備される。起動ファームウェアの問題の是正には、ＢＩＯＳファームウェア１９２のみの１つのコードモジュールに対する更新が必要である場合、ＢＩＯＳファームウェア１９２のモノリシックな画像全体がフラッシュメモリ１９０にダウンロードされる必要がある。
【００２５】
プロセッサ１１０は、さらに、ビデオコントローラ、ＳＣＳＩ（small computer system interface）コントローラ、ネットワークコントローラ、ＵＳＢ（universal serial bus）コントローラ、入力デバイス（キーボード、マウス等）といったさらなるコンポーネントと通信可能に連結されてよい。プラットフォーム１００はさらに、メモリコントローラハブ、入出力（Ｉ／Ｏ）コントローラハブ、ＰＣＩルートブリッジ等の１以上のブリッジまたはハブを含むことで、様々なシステムコンポーネントと通信可能に連結することができる。ここで利用する用語「バス」は、ポイントツーポイント通路の他にも共有通信経路のことを示すのに利用される。
【００２６】
例えばネットワークコントローラ１６０等の一部のコンポーネントは、バスと通信するためのインタフェース（例えばＰＣＩコネクタ）を含むアダプタカードとして実装されてよい。一実施形態では、プログラム可能な、またはプラグラム不可能なロジックデバイスまたはアレイ、ＡＳＩＣ（特定用途向け集積回路）、埋め込みコンピュータ、スマートカード等のコンポーネントを用いて、１以上のデバイスを埋め込みコントローラとして実装することができる。
【００２７】
ここで利用される用語「処理システム」および「データ処理システム」は、単一のマシン、または、互いに協同して動作する通信可能に連結されたマシンまたはデバイスのシステムを幅広く含む概念である。例示的な処理システムには、これらに限定はされないが、分散型コンピューティングシステム、スーパコンピュータ、高性能コンピューティングシステム、コンピューティングクラスタ、メインフレームコンピュータ、ミニコンピュータ、クライアント−サーバシステム、パーソナルコンピュータ、ワークステーション、サーバ、ポータブルコンピュータ、ラップトップコンピュータ、タブレット、電話機、ＰＤＡ（携帯情報端末）、ハンドヘルドデバイス、オーディオおよび／またはビデオデバイス等の娯楽デバイス、およびその他の情報処理送信デバイスが含まれる。
【００２８】
プラットフォーム１００は、少なくとも部分的には、キーボード、マウス等の従来の入力デバイスからの入力により、および／または、別のマシン、計測生物学上のフィードバック、またはその他の入力ソースまたは信号から受信するコマンドにより制御されてよい。プラットフォーム１００は、１以上の遠隔データ処理システム（不図示）への１以上の接続を、ネットワークインタフェースコントローラ（ＮＩＣ）１６０、モデム、その他の通信ポートまたはカップリングを介して、利用することができる。
【００２９】
プラットフォーム１００は、他の処理システム（不図示）に、物理および／または論理ネットワーク（例えばローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、イントラネット、インターネット等）により相互接続されてよい。ネットワークを必要とする通信は、様々な有線および／または無線の近接型または遠隔型のキャリアおよびプロトコル（無線周波数（ＲＦ）、衛星、マクロ波、ＩＥＥＥ８０２．１１規格、ブルートゥース（登録商標）、光学、赤外線、ケーブル、レーザ等）を利用してよい。
【００３０】
図２は、本発明の一実施形態における自動化されたモジュール型起動ファームウェア更新を可能とする図１のＭＥ１３０および企業システム１７０のさらなる詳細を示す。ＭＥ１３０は、プラットフォーム１００に対して自動化された起動ファームウェアモジュール更新を行うロジックを含み、バンド外通信チャネル１７１を介して企業サービス１７０の起動ファームウェアモジュール更新サービス２７０と通信する。
【００３１】
チップセット１２０内では、ＭＥ１３０が、図１のチップセットファームウェア１９６のロードのあとに示されている。ＭＥ１３０は、基本動作機能をＭＥ１３０に提供するＭＥカーネル２１０と、ネットワーク通信、セキュリティ、暗号、およびタイマサービス等の基本サービスを提供するＭＥ共通サービス２２０とを含む。ＭＥ１３０は、バンド外（ＯＯＢ）通信モジュール２３０をさらに含む。ＯＯＢ通信モジュール２３０は、プラットフォーム１００のコンポーネントと、対応する企業サービス１７０のコンポーネントとの間を、ネットワークコントローラ１６０を介して通信させる。ＭＥ２３０はさらに、起動ファームウェアモジュール更新処理を管理する起動ファームウェアモジュール更新マネージャ２４０を含む（以下で詳述する）。
【００３２】
ＭＥ１３０はさらに、管理モジュール２５０、セキュリティモジュール２５５、および盗難検知モジュール２６０を含む。これらのモジュールを企業サービス１７０と共同して利用することで、プラットフォーム１００等のプラットフォームの構成および管理の企業全体のポリシーとの一貫性が維持される。ＯＯＢサーバ通信モジュール２３０は、管理モジュール２５０、セキュリティモジュール２５５、および盗難検知モジュール２６０の間の、ネットワークコントローラ１６０を介した企業サービス１７０の対応するコンポーネント（不図示）との通信を可能とする。
【００３３】
本発明の一実施形態においては、起動ファームウェアモジュール更新マネージャ２４０は、起動ファームウェアモジュール更新サービス２７０と協同して、自動化されたモジュール型起動ファームウェア更新を可能とする。ＯＯＢ通信モジュール２３０は、モジュール型起動ファームウェア更新マネージャ２４０と起動ファームウェアモジュール更新サービス２７０との間でネットワークコントローラ１６０を介した通信を行わせる。一実施形態では、バンド外通信チャネル１７１を利用して、更新された起動ファームウェアコードモジュールをプラットフォーム１００へ転送する。示されている実施形態では、企業サービス１７０は、ホストシステムにインストールされている起動ファームウェアコードモジュールのバージョン、暗号鍵、その他の起動ファームウェアモジュール更新サービス２７０が利用するデータ等の情報を格納する企業データレポジトリ１７２を有する。起動ファームウェアモジュール更新マネージャ２４０および起動ファームウェアモジュール更新サービス２７０の動作については、さらに図３を参照して後述する。
【００３４】
図３は、本発明の一実施形態における自動化されたモジュール型起動ファームウェア更新を行う、起動ファームウェアモジュール更新マネージャと企業起動ファームウェアモジュール更新サービスとの間の相互作用を示すフロー図である。
【００３５】
図１および図２の企業サービス１７０は、プラットフォーム１００等のプラットフォームの構成および管理の企業全体のポリシーとの一貫性を維持するよう動作する。企業サービス１７０およびプラットフォーム１００のＯＯＢ通信チャネル１７１を介した通信中に、起動ファームウェアモジュール更新マネージャ２４０および起動ファームウェアモジュール更新サービス２７０は、プラットフォーム１００上で起動ファームウェアコードモジュールに関する通信を行うことができる。
【００３６】
アクション３．１で、起動ファームウェアモジュール更新マネージャ２４０は、起動ファームウェア更新に関する照会を、起動ファームウェアモジュール更新サービス２７０に対して行う。アクション３．２で、プラットフォーム１００に関する起動ファームウェアコードモジュールが更新されていた場合には、起動ファームウェアモジュール更新サービス２７０は、起動ファームウェア更新要求を、更新されたコードモジュール／ドライバとともに起動ファームウェアモジュール更新マネージャ２４０へ送る。図３は起動ファームウェアモジュール更新マネージャ２４０による通信開始が示されているが、本発明の範囲内には、起動ファームウェアモジュール更新マネージャ２４０と起動ファームウェアモジュール更新サービス２７０との間の通信が、起動ファームウェアモジュール更新サービス２７０のサーバ側から始めることも含まれる。
【００３７】
アクション３．３で、起動ファームウェアモジュール更新マネージャ２４０が更新されたコードモジュール／ドライバの整合性をチェックする（これには、更新要求が正当なものであることを確かめ、送り手の身元が起動ファームウェアモジュール更新サービス２７０であることを確かめることが含まれる）。一実施形態においては、起動ファームウェアモジュール更新マネージャ２４０は、更新されたコードモジュール／ドライバコンテンツからの署名を計算して、計算された署名を、更新されたモジュール／ドライバに付随する整合性保護（暗号化）マニフェスト内に起動ファームウェアモジュール更新サービス２７０が供給する署名と比較することにより、起動ファームウェア更新の整合性を検証する。この、コードモジュール／ドライバコンテンツに基づく署名の比較により、更新されたモジュール／ドライバが、起動ファームウェアモジュール更新サービス２７０からの送信中に傍受されなかったことが証明される。更新されたコードモジュール／ドライバはさらに暗号化により保護され、起動ファームウェアモジュール更新マネージャ２４０は、復号鍵を取得して、更新されたコードモジュール／ドライバを復号化する。一実施形態では、暗号／復号鍵は、チップセット１２０およびＭＥ１３０の製造中に図１のフラッシュメモリ１９０のデータ領域１９８に格納され、起動ファームウェアモジュール更新マネージャ２４０によりフラッシュメモリ１９０から取得される。
【００３８】
更新されたコードモジュール／ドライバの整合性がアクション３．３で確かめられた場合には、起動ファームウェアモジュール更新マネージャ２４０は、ファームウェアボリュームを、更新されたコードモジュール／ドライバによりアクション３．４で更新する。一実施形態では、更新されたコードモジュール／ドライバは、ファームウェアボリュームの別個の専用パーティションに配置されて、モジュール更新を行い、一方で、元の起動ファームウェアコードモジュールのモノリシックな画像は、ファームウェアボリュームの異なるパーティションに存在している。起動ファームウェアモジュール更新マネージャ２４０は、ファームウェアボリュームのパーティションを管理し、起動ファームウェアモジュール更新マネージャ２４０のみがファームウェアボリュームのモジュール更新パーティションに書き込みアクセスを有する。ファームウェアボリュームのモジュール更新パーティションも、更新されたコードモジュール／ドライバの識別子を格納し、更新されたコードモジュール／ドライバの識別子は、元のコードモジュール／ドライバの代わりに、更新されたコードモジュール／ドライバの利用を可能にする。
【００３９】
アクション３．５で、起動ファームウェアモジュール更新マネージャ２４０は、起動モジュール更新サービス２７０に、起動ファームウェア更新要求のステータスを通知する。更新されたコードモジュール／ドライバがファームウェアボリュームのモジュール更新パーティションにロードされると、システム起動時に自動的にロードされる。アクション３．６で、起動ファームウェアモジュール更新マネージャ２４０は、システムを再起動して、更新されたコードモジュール／ドライバを起動せよ、との要求を発行することができる。システム起動シーケンスについては図４を参照して後で詳述する。アクション３．６の結果行われるシステム起動シーケンス中に、起動ファームウェアモジュール更新ディスパッチャを呼び出して、元のコードモジュール／ドライバを、更新されたコードモジュール／ドライバで置き換えさせる。起動ファームウェアモジュール更新ディスパッチャが起動シーケンス中に行うアクションについては、図５および図６を参照してさらに後述する。
【００４０】
起動シーケンス中に、起動ファームウェアモジュール更新マネージャ２４０は、アクション３．７に示す起動ファームウェアモジュール更新サービス２７０へのメッセージにより通信することのできる情報を取得することができる。例えば、ドライバディスパッチャ（図４および図６を参照して後述する）が、起動ファームウェアモジュール更新マネージャ２４０に、更新されたコードモジュール／ドライバの処理が開始されるときを通知することができる。アクション３．８で、様々な起動ファームウェアコードモジュールがメモリにロードされた後で、ＢＩＯＳ３１０は、更新されたコードモジュール／ドライバで起動させる試みを行う。ＢＩＯＳ３１０が起動に失敗すると、ＢＩＯＳ３１０を再起動させる別の試みが、元のモノリシックな画像が存在するファームウェアボリュームのパーティションに格納されている元の起動ファームウェアコードモジュールの画像からの元のバージョンのコードモジュール／ドライバにより、行われる。
【００４１】
アクション３．９では、起動ファームウェア更新マネージャ２４０は、ドライバディスパッチャからコードモジュール／ドライバ更新のステータスに関する情報を受信する。例えば、更新された起動ファームウェアコードモジュールがメモリにロードされていても、適切な実行に失敗している場合がある。アクション３．１０で、起動ファームウェア更新マネージャ２４０は、アクション３．２で起動ファームウェアモジュール更新サービス２７０が要求した起動ファームウェア更新のステータスとともに、受領確認メッセージを起動ファームウェアモジュール更新サービス２７０に送る。
【００４２】
システム起動シーケンス中に、一連のハードウェア初期化段階が、電力供給から、オペレーティングシステムのロードまで行われ、システムの制御を担う。起動シーケンスは、ここでは、ＵＲＬ（www-intel-com/technology/framework）から情報入手可能なＥＦＩ（Extensible Firmware Interface）アーキテクチャ仕様（バージョン０．９、２００３年９月１６日）に関するインテル（登録商標）プラットフォームイノベーションフレームワークに則った説明を行う。主にフレームワーク起動シーケンスは図４を参照して行われ、本発明の後続する説明のコンテキストを提供する。本発明はこの特定の説明のフレームワーク内での動作に限定はされない。
【００４３】
図４は、本発明の一実施形態のコンポーネントが動作する起動シーケンスの各段階を示す。フレームワーク起動シーケンスは、システムに電力供給が行われると実行されるセキュリティ段階４１０により始まる。事前検証器４１１は、セキュリティ段階４１０中に実行されて、ＢＩＯＳを認証する。既存のシステムでは、事前検証器４１１およびＳＥＣ段階４１０は、ＣＲＴＭ（Core Root of Trust for Measurement）、つまり、ＢＩＯＳコードを認証するのに十分なコードを提供し、プラットフォーム上でサポートされている場合、ＴＰＭ（Trusted Platform Module）を開始する。ＴＰＭに関するさらなる情報はＵＲＬ（www-trustedcomputinggroup-org）から入手可能である。
【００４４】
セキュリティ段階４１０が完了すると、ＥＦＩ前の初期化（ＰＥＩ）段階４２０で、プロセッサ４２１、チップセット４２３、およびマザーボード４２５を初期化する。ＰＥＩ段階４２０では、後続する段階のコードを含むシステムＲＡＭおよびファームウェアボリュームの最小量が初期化および記述される。ＰＥＩ段階４２０において、ＥＦＩドライバディスパッチャ４３２および固有サービス４３４をドライバ実行環境（driver eXecution environment：  ＤＸＥ）段階４３０でセキュアに起動する準備を行う。ＤＸＥ段階４３０では、ＥＦＩドライバディスパッチャ４３２がデバイス、バス、およびサービスドライバ４３６をロードするよう動作し、起動マネージャをサポートしてオペレーティングシステムを起動することのできる環境を構築する。本発明を参照すると、修正されたバージョンのＥＦＩドライバディスパッチャは、ここでは起動ファームウェアモジュール更新ディスパッチャと称され、ＤＸＥ段階４３０で利用される。ＤＸＥ段階４３０に続いて、起動デバイス選択（ＢＤＳ）段階４４０で起動マネージャ４４２をロードする。ＢＤＳ段階４４０に続いて、非常システムロード（ＴＳＬ）段階４５０が、オペレーティングシステム起動中に生じる。起動マネージャ４４２は、非常ＯＳ起動ローダ４５６を起動して、これにより、ＯＳ不在のアプリケーション４５２を実行可能な非常ＯＳ環境４５４を作成する。起動マネージャ４４２はさらに、オペレーティングシステムを起動する最終ＯＳ起動マネージャ４５８を起動する。ランタイム段階４６０でシステムは、ＯＳの存在するアプリケーション４６２を実行可能な最終ＯＳ環境４６４を作成する。ランタイム段階４６０中にシステムは、オペレーティングシステムの制御の下で動作する。ＯＳランタイム中にシステムエラーが生じると（ＲＴ段階４６０）、ファームウェアＰＥＩ段階４２０およびＤＸＥ段階４３０のフローは、生存後段階４７０で再構築され、ＯＳの存在する復帰アクティビティを行わせることができる。
【００４５】
本発明における、更新された起動ファームウェアコードモジュール／ドライバのロードは、ドライバ実行環境（ＤＸＥ）段階４３０中に、起動ファームウェアモジュール更新ディスパッチャの制御の下で行われ、これは、本発明の実施形態におけるモジュール型起動ファームウェア更新を行う図４の修正バージョンのＥＦＩドライバディスパッチャ４３２に相当する。起動ファームウェアモジュール更新ディスパッチャの動作については図５および図６を参照して後で詳述する。
【００４６】
図５は、本発明の一実施形態におけるシステムを起動するときのモジュール型起動ファームウェア更新を行う方法のフローチャートである。ステップ５１０の「起動中に、ＢＩＯＳモジュール更新ディスパッチャが、モジュールＢＩＯＳ更新ファームウェアボリュームパーティション内に、更新されたドライバがないか検査する」では、起動ファームウェアモジュール更新ディスパッチャが、ファームウェアボリュームのモジュール更新パーティション内に、更新されたコードモジュール／ドライバがないか検査する。次に制御は、ステップ５２０の「起動ファームウェアモジュール更新ディスパッチャが、ＢＩＯＳモジュール更新ファームウェアボリュームパーティションから、更新されたドライバをロードする」に移り、ここでは、起動ファームウェアモジュール更新ディスパッチャが、ファームウェアボリュームの異なるパーティションに格納されているモノリシックＢＩＯＳ画像からの元のコードモジュール／ドライバの代わりに、更新されたコードモジュール／ドライバをメモリにロードする。次に制御はステップ５３０の「ＢＩＯＳを起動する」に進み、ここでＢＩＯＳを図４のＤＸＥ段階４３０の最後に起動する。次に制御は「更新されたドライバにエラーが生じた？」の判断点４３０へ進み、ここで、ＢＩＯＳ起動中に、更新されたドライバにエラーが生じたか否かを判断する。更新されたドライバにエラーが生じた場合、制御はステップ５４０の「元のファームウェアボリュームパーティションから元のドライバをロードする」に進み、ファームウェアボリュームの元のパーティションに格納されているモノリシックなＢＩＯＳ画像から、元のコードモジュール／ドライバをロードする。次に制御は、ステップ５５０「ＯＳの起動を続行する」に進み、オペレーティングシステムの起動シーケンスを続行する。起動シーケンス続行中に、制御はステップ５６０の「起動ファームウェアモジュール更新のステータスをサーバに提供する」に進み、ここで図３を参照して記載したように、ＢＩＯＳモジュール更新マネージャ２４０が、起動ファームウェアモジュール更新サービス２７０に対してステータス更新を提供する。次に制御はステップ５７０の「サーバが、起動ファームウェアモジュール更新のステータスに応答する」に進み、ここで起動ファームウェアモジュール更新サービス２７０は、モジュール型起動ファームウェア更新に関して受信したステータスメッセージに対して応答することができる。例えば、モジュール型起動ファームウェア更新にエラーが生じた場合、起動ファームウェアモジュール更新サービス２７０は、別のバージョンの更新されたコードモジュール／ドライバを後続する更新要求で提供することができる。
【００４７】
図６は、本発明の一実施形態において、実自動化されたモジュール型起動ファームウェア更新が実行された後のシステムの起動を示すフロー図である。図６のフロー図は、ＤＸＥ段階６３０およびＢＤＳ段階６４０中に起こったアクティビティを示し、これは、図４のＤＸＥ段階４３０およびＢＤＳ段階４４０に対応している。ＤＸＥ段階６３０の実行前に、図４のＳＥＣ段階４１０に類似したセキュリティ段階およびＰＥＩ段階４２０に類似したＰＥＩ段階が実行された。前のＰＥＩ段階では、ハンドオフブロックリスト６０４が初期化された（これは、プロセッサ、チップセット、およびメインメモリの初期化を行っている間に起動シーケンスの前の段階から渡された情報を含むデータ構造である）。ハンドオフブロックリスト６０４は、ファームウェアボリュームハードウェア６２０に見つかるファームウェアボリュームを含む、システムの初期化中に発見されたファームウェアボリュームに関する情報を含む。例えば、図１に示すシステム起動中のＰＥＩ段階では、ＢＩＯＳファームウェア１９２およびチップセットファームウェア１９６それぞれのパーティションを含むファームウェアボリュームが発見される。発見された各別個のファームウェアボリュームは、ＰＥＩ段階が提供するハンドオフブロックをそれぞれ有してよい。ハンドオフブロックリスト６０４は、ファームウェアファイルを含むファームウェアボリュームの位置の詳細を示し、各ファームウェアボリュームのベースアドレスと長さとを含む。ＤＸＥの最初のプログラムロード（ＩＰＬ）初期化モジュールは、ハンドオフブロックリスト６０４を利用して、ＤＸＥ基礎ファームウェアファイルの位置を発見する。
【００４８】
前のＰＥＩ段階では、さらに、ＤＸＥ基礎コード６０６が発見および起動される。ＤＸＥ基礎コード６０６は、一式の起動サービス、ランタイムサービス、およびＤＸＥサービスを生成する。ＤＸＥ基礎コード６０６は、ハンドオフブロックリスト６０４を利用して、実行するドライバを発見する。ＤＸＥ基礎コード６０６は、プロセッサ、チップセットまたはプラットフォームに依存しない、完全な可搬性を有するよう設計される。ＤＸＥ基礎コード６０６の初期状態は、ハンドオフブロックリスト６０４のみに依存する。この単一の依存性は、ＤＸＥ基礎コード６０６が前の段階のいかなるサービスにも依存しないことを意味しており、従って全ての前の段階は、ハンドオフブロックリスト６０４がＤＸＥ基礎コード６０６に渡されてはじめてアンロードが可能となる。ＤＸＥ基礎コード６０６は、ハードコード化されたアドレスは含まない。この結果、ＤＸＥ基礎コード６０６は、物理メモリの何処にでもロード可能となり、物理メモリまたはファームウェアボリュームがプロセッサの物理アドレス空間のいずれに位置していようとも正確な機能が可能となる。ＤＸＥ基礎コード６０６は、プロセッサ固有の情報、チップセット固有の情報、またはプラットフォーム固有の情報のいずれも含まない。代わりに、ＤＸＥ輝度コード６０６は、一式のアーキテクチャプロトコルインタフェースによりシステムハードウェアから抽象化される（abstracted）。これらアーキテクチャプロトコルインタフェースは、ＤＸＥディスパッチャが呼び出す一式のＤＸＥドライバにより生成され、ここでは起動ファームウェアモジュール更新ディスパッチャ６１０と称される。
【００４９】
ＤＸＥ基礎コード６０６は、ＥＦＩシステムテーブルおよびそれに関連する一式のＥＦＩ起動サービスおよびＥＦＩランタイムサービスを生成する。ＤＸＥ基礎コード６０６はさらに、起動ファームウェアモジュール更新ディスパッチャ６１０を含む。ＤＸＥ基礎コード６０６の起動後に、制御はＤＸＥディスパッチャに渡され、これは本ケースでは起動ファームウェアモジュール更新ディスパッチャ６１０であり、これはハンドオフブロックリスト６０４等のハンドオフブロックで記載されているファームウェアボリュームに見つかるＤＸＥドライバをロードして呼び出す機能を有する。
【００５０】
ファームウェアボリュームハードウェア６２０は、ファームウェアコードおよび／またはデータを含む永続性物理レポジトリである。ファームウェアボリュームハードウェアは通常は図１のフラッシュメモリ１９０等のフラッシュコンポーネントであるが、他の種類の永続性記憶装置であってもよい。単一の物理ファームウェアデバイスを小片に分割して、複数の論理ファームウェアデバイスを形成することもできる。同様に、複数の物理ファームウェアデバイスが１つのより大きな論理ファームウェアデバイスに統合されてもよい。論理ファームウェアデバイスはファームウェアボリュームと称される。ＥＦＩフレームワークでは、データおよび／またはコード用の基礎記憶レポジトリがファームウェアボリュームである。各ファームウェアボリュームは１つのファイルシステムに組織化される。このようにして、ファイルがＥＦＩフレームワークファームウェアの格納／記憶の基本単位となる。
【００５１】
ファームウェアボリュームに含まれているファイルがセキュリティ（ＳＥＣ）またはＥＦＩ前の初期化（ＰＥＩ）段階から、または、初期にドライバ実行環境（ＤＸＥ）段階にアクセスされる場合、ファームウェアボリュームはメモリマッピングされ、フレームワークファームウェアファイルシステム（ＦＦＳ）フォーマットを遵守しており、これは、ＥＦＩファームウェアファイルシステム仕様に関するインテル（登録商標）プラットフォームイノベーションフレームワークに定義されており、ＵＲＬ（www-intel-com/technology/framework）から情報入手可能である。ＳＥＣ、ＰＥＩ、およびＤＸＥ段階は次に、ＦＦＳおよびフレームワークファームウェア画像フォーマットを適宜パースする。
【００５２】
起動ファームウェアモジュール更新ディスパッチャ６１０は、ハンドオフブロックリスト６０４に記載されているファームウェアボリュームからドライバを探す。ファームウェアボリュームは、先験的な（a priori）ファイルと称される関連ファイルを有する場合があり、このファイルは、第一にロードおよび実行されるべきＤＸＥドライバのリストを含んでいる。先験的なファイル内のＤＸＥドライバがロードおよび実行されると、ファームウェアボリュームの残りのＤＸＥドライバの依存表現を評価して、それらのロードおよび実行順序を決定する。
【００５３】
一実施形態では、先験的なファイルのＤＸＥドライバおよび依存表現が真と評価されたＤＸＥドライバ全てをロードおよび実行した後に、制御を起動ファームウェアモジュール更新ディスパッチャ６１０からＢＤＳ６４２に渡す。ＢＤＳ６４２は、コンソールデバイスを構築し、ＢＤＳ段階６４０でオペレーティングシステムの起動を試みる役割を果たす。コンソールデバイスが構築され、起動デバイスへのアクセスが構築されるときに、さらなるファームウェアボリュームを発見することもある。ＢＤＳ６４２がコンソールデバイスを開始したり起動デバイスへのアクセスを得たりできない場合、起動ファームウェアモジュール更新ディスパッチャ６１０を再度呼び出す。この呼び出しにより、起動ファームウェアモジュール更新ディスパッチャ６１０は、起動ファームウェアモジュール更新ディスパッチャ６１０が最後に呼び出されてから発見されたファームウェアボリュームからのＤＸＥドライバ６３２をロードおよび実行する。起動ファームウェアモジュール更新ディスパッチャが可能な限り全てのＤＸＥドライバ６３２をロードおよび実行すると、制御は再度ＢＤＳ６４２に戻り、ＯＳ起動処理を続行する。
【００５４】
ＥＦＩファームウェアボリュームプロトコルは、ＤＸＥ段階中に実行されているプログラムに、ファームウェアボリューム（メモリマッピングされていないファームウェアボリュームおよびＦＦＳを実装しないファームウェアボリュームを含む）にアクセスさせる。示されている実施形態では、ＢＩＯＳ／モジュール更新ディスパッチャ６１０は、ファームウェアボリュームプロトコルドライバ６２６によりＥＦＩファームウェアボリュームプロトコルに含まれているファイル抽象化を用い、ファームウェアボリュームにアクセスする。
【００５５】
示されている実施形態では、ファームウェアボリュームプロトコルをファームウェアボリュームプロトコルドライバ６２６により生成し、ファームウェアボリュームプロトコルドライバ６２６はファイルシステムドライバとして機能し、ファームウェアボリュームブロックプロトコルドライバ６２４がファームウェアボリュームハードウェア６２０へのアクセス用に実装するＥＦＩファームウェアボリュームブロックプロトコルを利用する。ファームウェアボリュームブロックプロトコルドライバ６２４は、ファームウェアボリュームハードウェア６２０に対してブロックレベルのアクセスを提供する。ＥＦＩファームウェアボリュームブロックプロトコルを実装するとして示されているドライバ６２４および６２６は、ファームウェアボリュームハードウェア６２０を抽象化するが、ファームウェアボリュームブロックドライバの下の任意の数の抽象化を利用してプラットフォーム要件を満たすこともできる。ＥＦＩファームウェアボリュームブロックプロトコルは、バイトレベルの読み書き機能およびブロックレベルの消去機能を提供する。ＥＦＩファームウェアボリュームブロックプロトコルはさらに、デバイスハードニング特徴を露呈する（例えば、ファームウェアを不要な上書きおよび／または消去から保護する必要が出てくる等）。ファームウェアボリュームプロトコルドライバ６２６等のファイルシステムドライバは、ファームウェアボリュームブロックプロトコルドライバの上部に積層されてファームウェアボリュームにファイルレベルのアクセスを可能とする。ファームウェアボリュームプロトコルは、存在しうるハードウェアデバイスハードニング特徴およびファームウェアボリュームをフォーマットするのに利用されるファイルシステムを抽象化する。ファームウェアボリュームプロトコルに関する情報を含むさらなる情報については、ＵＲＬ（www-intel-com/technology/framework）から情報入手可能な、ＥＦＩファームウェアファイルシステム仕様に関するインテル（登録商標）プラットフォームイノベーションフレームワークを参照されたい。
【００５６】
起動ファームウェアモジュール更新ディスパッチャ６１０は、起動前段階に動作して、実行用にドライバをスケジュールする。一実施形態では、起動ファームウェアモジュール更新ディスパッチャ６１０は、ファームウェアボリュームからのＤＸＥドライバをロードおよび実行するディスパッチサービス、ファームウェアボリュームに格納されているコンポーネントのＳＯＲ（schedule on require）フラグをクリアするスケジュールサービス、ファームウェアボリュームに格納されているファイルの状態を不信任状態から信任状態に変更する信任サービス、および、システムメモリに存在するファームウェアボリューム用のファームウェアボリューム処理を作成する処理ファームウェアボリュームサービス（ProcessFirmwareVolume）を提供する。一実施形態では、起動ファームウェアモジュール更新ディスパッチャは、利用可能な全てのファームウェアボリュームを探し、バージョン情報に基づいてロードされるドライバ／コードモジュールのリストを作成する。上述したように、起動ファームウェアモジュール更新ディスパッチャ６１０は先ず更新されたドライバ６２２用のＦＶパーティションに、更新されたドライバがないかを探し、その後に、ファームウェアボリュームの別のパーティションに元のドライバがないかを探す。更新対象の起動ファームウェアコードモジュールは、起動前のロードが必要な最新のＥＦＩドライバ／モジュールを定義するバージョンストリングを有する。
【００５７】
ここで記載した起動ファームウェアモジュール更新メカニズムにより、個々の起動ファームウェアコードモジュールを、全起動ファームウェアのモノリシックな画像のダウンロードおよび更新を必要とせずに更新することができるようになる。ここで記載した技術により、更新されたモジュール／ドライバの整合性チェック機能を持つセキュリティが提供され、ユーザがモジュール型起動ファームウェア更新を受信する際に自身のシステムを再起動する必要がなくなることから、よりユーザフレンドリな更新処理が提供される。
【００５８】
ここで記載した技術は、さらに、新たに更新されたコードモジュール／ドライバにエラーが出た場合にでも元のコードドライバ／モジュールを利用してシステムを起動することができ、試行された更新前と同じ機能を続行することができることからエラー耐性もある。エラーを起こしたモジュールについてサーバにはフィードバックが行われ、是正されたコードモジュール／ドライバを、後続する更新要求に対して提供することができる。
【００５９】
図７は、本発明の一実施形態における起動ファームウェアモジュール更新マネージャを実装する仮想マシン環境を示す。プラットフォーム７００が仮想化されると単一のプロセッサしか含まないが、ホスト上の仮想マシンモニタ（「ＶＭＭ７３０」）が複数の抽象および／または複数のホストのビューを提供することで、ホストの下層にあるハードウェアは１以上の独立したオペレーティングＶＭ（仮想マシン）として見えるようになる。ＶＭＭ７３０は、ソフトウェア（例えば独立型プログラムおよび／またはホストオペレーティングシステムのコンポーネントとして）、ハードウェア、ファームウェア、および／または、これらの任意の組み合わせとして実装されてよい。ＶＭＭ７３０は、ホスト上のリソースの割り当てを管理し、ラウンドロビン方式その他の所定のスキームで様々なＶＭ間のサイクルを実行するのに必要なコンテキストスイッチを行う。当業者であれば、例示されているのが１つのプロセッサのみであっても（「プロセッサ７０５」）、本発明の実施形態がそれに限定されるわけではなく、仮想化された環境内で複数のプロセッサを利用することができることを容易に理解するであろう。
【００６０】
２つのＶＭパーティションのみが示されているが（「ＶＭ７１０」および「ＶＭ７２０」、ここでは「ＶＭ」と総称する）、これらＶＭはあくまで例示であって、さらなる仮想マシンをホストに追加することもできる。ＶＭ７１０およびＶＭ７２０は、それぞれ内蔵タイプのプラットフォームとして機能して、銘々の「ゲストオペレーティングシステム」（つまり、ＶＭＭ７３０がホストするオペレーティングシステムであって、「ゲストＯＳ７１１」および「ゲストＯＳ７２１」として示され、ここでは「ゲストＯＳ」と総称されるもの）および他のソフトウェア（「ゲストソフトウェア７１２」および「ゲストソフトウェア７２２」として示され、ここでは「ゲストソフトウェア」と総称されるもの）を実行する。
【００６１】
各ゲストＯＳおよび／またはゲストソフトウェアは、仮想マシンではなくて専用コンピュータ上で動作しているかのように動作する。つまり、各ゲストＯＳおよび／またはゲストソフトウェアは、様々なイベントを制御してプラットフォーム７００上のハードウェアリソースへアクセスすることが期待されていてよい。各ＶＭ内では、ゲストＯＳおよび／またはゲストソフトウェアが、実際にプラットフォーム７００の物理ハードウェア（ネットワークコントローラ７６０を含みうる「ホストハードウェア７４０」）上で動作しているかのように振る舞うことができる。
【００６２】
図１のＭＥ１３０のような専用プロセッサを有する物理ハードウェアパーティションは、仮想化されたパーティション（図７のような）よりも高いレベルのセキュリティを提供することができるが、本発明の実施形態がいずれの環境および／またはこれら環境の組み合わせで実施されることで様々なレベルのセキュリティを実現することができることは当業者には自明である。また当業者であれば、ＭＥ、ＡＭＴ、またはＰＲＬプラットフォームが仮想化された環境内で実装可能であることを理解する。例えば、ＶＭ７２０はホスト上のＭＥパーティションに特化していてよく、一方でＶＭ７１０はホスト上の通常アプリケーションを実行する。このシナリオでは、ホストは複数のプロセッサを含んでも含まなくてもよい。ホストが２つのプロセッサを含む場合、例えばＶＭ７２０は他のプロセッサを割り当てられてよく、ＶＭ７１０は（およびホスト上の他のＶＭは）プロセッサ７０５のリソースを共有してよい。他方で、ホストが単一のプロセッサのみを含む場合、プロセッサは両方のＶＭとして機能することができるが、ＶＭ７２０は依然として、ＶＭＭ７３０と協同して、ホスト上の他のＶＭから隔離されていてよい。簡略化目的から、本発明の実施形態をＭＥ環境で記載したが、本発明の実施形態はこれに限定されない。つまり、ＭＥに関する「パーティション」「セキュアなパーティション」「セキュリティパーティション」および／または「管理パーティション」といった言及は、全ての物理および／または仮想パーティションを含む（これは上述した通りである）。
【００６３】
ここに開示したメカニズムの実施形態は、ハードウェア、ソフトウェア、ファームウェア、これら実装例の組み合わせでの実装が可能である。本発明の実施形態は、少なくとも１つのプロセッサ、データ記憶システム（揮発性および不揮発性メモリおよび／または記憶素子を含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含むプログラム可能システム上で実行されるコンピュータプログラムとしての実装が可能である。
【００６４】
プログラムコードを入力データに適用することで、ここで開示されている機能を行い、出力情報を生成することができる。本発明の実施形態はさらに、本発明の動作を行うための命令、あるいはここで開示されている構造、回路、装置、プロセッサおよび／またはシステムの特徴を定義するＨＤＬ等の設計データを含むマシンアクセス可能な媒体を含む。これら実施形態はプログラムプロダクトとも称される場合がある。
【００６５】
これらマシンアクセス可能な記憶媒体は、ハードディスク等の記憶媒体、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、光磁気ディスクを含む任意の他の種類のディスク、ＲＯＭ、ＤＲＡＭ、ＳＲＡＭ、ＥＰＲＯＭ、ＦＬＡＳＨ、ＥＥＰＲＯＭ（登録商標）等のＲＡＭ等の半導体デバイス、磁気カードまたは光カード、または任意の他の種類の電子命令の格納に適した媒体を含む、マシンまたはデバイスが製造または形成する粒子の有形の配列を含んでよいが、これらに限定はされない。
【００６６】
出力情報は、１以上の出力デバイスに公知の方法で適用することができる。この適用に際して、処理システムは、ＤＳＰ、マイクロコントローラ、ＡＳＩＣ、あるいはマイクロプロセッサ等のプロセッサを有する任意のシステムを含む。
【００６７】
プログラムは、処理システムと通信するために高レベルのプロシージャのまたはオブジェクト指向のプログラミング言語で実装することができる。さらにプログラムは適宜アセンブリ言語または機械言語で実装されてもよい。ここで記載したメカニズムの範囲は、特定のプログラミング言語に言質得されない。いずれにしても、言語はコンパイルされた、あるいは解釈された言語であってよい。
【００６８】
自動化された起動ファームウェアモジュール更新を行う方法およびシステムの実施形態を開示してきた。上記では本発明の特定の実施形態を示し、記載してきたが、当業者には添付請求項の範囲を逸脱せずとも多くの変更例、変形例、および修正例が可能であることが明らかである。従って当業者であれば、本発明を広義な意味で逸脱せずにこれら変更例および変形例が可能であることを理解する。添付請求項の範囲は、本発明の真の範囲および精神に含まれるこれら全ての変更例、変形例、および修正例が含むことを意図している。
【図１】
2011118873.tif 000003
【図２】
2011118873.tif 000004
【図３】
2011118873.tif 000005
【図４】
2011118873.tif 000006
【図５】
2011118873.tif 000007
【図６】
2011118873.tif 000008
【図７】
2011118873.tif 000009
【手続補正書】
【提出日】平成22年11月9日(2010.11.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピュータ実装される方法であって、
システムのセキュアなパーティションで、前記システムの複数の起動ファームウェアコードモジュールの１つの元の起動ファームウェアコードモジュールの置き換えとして、更新された起動ファームウェアコードモジュールを受信する段階と、
前記１つの元の起動ファームウェアコードモジュールのみを、前記更新された起動ファームウェアコードモジュールで自動的に置き換える段階と、
次に前記システムが起動されたときにユーザの介入を受けずに、前記システムの前記複数の起動ファームウェアコードモジュールにより、前記更新された起動ファームウェアコードモジュールを自動的に実行する段階と
を備える方法。
【請求項２】
ファームウェアボリュームの更新パーティションに前記更新された起動ファームウェアコードモジュールを書き込む段階をさらに備え、
前記ファームウェアボリュームの前記更新パーティションは、前記システムの起動時に前記複数の起動ファームウェアコードモジュールを含む前記ファームウェアボリュームの別のパーティションとともに読み出される請求項１に記載の方法。
【請求項３】
前記ファームウェアボリュームの前記更新パーティションに前記更新された起動ファームウェアモジュールを書き込む段階の前に、前記更新された起動ファームウェアモジュールの整合性を認証する段階をさらに備える請求項２に記載の方法。
【請求項４】
前記更新された起動ファームウェアモジュールは、前記セキュアなパーティションに連結されたバンド外通信チャネルを介してサーバにより提供される請求項１に記載の方法。
【請求項５】
前記更新された起動ファームウェアモジュールを受信する段階の前に前記サーバの整合性を認証する段階をさらに備える請求項４に記載の方法。
【請求項６】
前記更新された起動ファームウェアモジュールのロード中に問題が生じた場合、前記１つの元の起動ファームウェアコードモジュールをロードさせる段階をさらに備える請求項１に記載の方法。
【請求項７】
前記システムの起動後に、前記更新された起動ファームウェアコードモジュールのインストールステータスを、前記更新された起動ファームウェアコードモジュールの送信元であるサーバに提供する段階をさらに備える請求項１に記載の方法。
【請求項８】
システムであって、
ホストオペレーティングシステムと前記システムの複数の起動ファームウェアコードモジュールとを実行する少なくとも１つのプロセッサと、
前記プロセッサに連結され、前記ホストオペレーティングシステムから隔離されたセキュアなパーティションと、
前記セキュアなパーティションで、前記システムの複数の起動ファームウェアコードモジュールの１つの元の起動ファームウェアコードモジュールの置き換えとして、更新された起動ファームウェアコードモジュールを受信する手段と、
前記１つの元の起動ファームウェアコードモジュールのみを、前記更新された起動ファームウェアコードモジュールで自動的に置き換える手段と、
次に前記システムが起動されたときにユーザの介入を受けずに、前記システムの前記複数の起動ファームウェアコードモジュールにより、前記更新された起動ファームウェアコードモジュールを自動的に実行する手段と
を備えるシステム。
【請求項９】
ファームウェアボリュームの更新パーティションに前記更新された起動ファームウェアコードモジュールを書き込む手段をさらに備え、
前記ファームウェアボリュームの前記更新パーティションは、前記システムの起動時に前記複数の起動ファームウェアコードモジュールを含む前記ファームウェアボリュームの別のパーティションとともに読み出される請求項８に記載のシステム。
【請求項１０】
前記ファームウェアボリュームの前記更新パーティションに前記更新された起動ファームウェアモジュールを書き込む前に、前記更新された起動ファームウェアモジュールの整合性を認証する手段をさらに備える請求項９に記載のシステム。
【請求項１１】
前記更新された起動ファームウェアモジュールは、前記セキュアなパーティションに連結されたバンド外通信チャネルを介してサーバにより提供される請求項８に記載のシステム。
【請求項１２】
前記更新された起動ファームウェアモジュールの受信前に前記サーバの整合性を認証する手段をさらに備える請求項１１に記載のシステム。
【請求項１３】
前記更新された起動ファームウェアモジュールのロード中に問題が生じた場合、前記１つの元の起動ファームウェアコードモジュールをロードさせる手段をさらに備える請求項８に記載のシステム。
【請求項１４】
前記システムの起動後に、前記更新された起動ファームウェアコードモジュールのインストールステータスを、前記更新された起動ファームウェアコードモジュールの送信元であるサーバに提供する手段をさらに備える請求項８に記載のシステム。
【請求項１５】
コンピュータに、請求項１から請求項７のいずれか一項に記載の方法を実行させるプログラム。
【外国語明細書】
2011118873000001.pdf