特許 7382446 プラットフォームファームウェア回復実行からの起動失敗を回避する方法及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-08

(45)【発行日】2023-11-16

(54)【発明の名称】プラットフォームファームウェア回復実行からの起動失敗を回避する方法及びシステム

(51)【国際特許分類】

   G06F 21/57 20130101AFI20231109BHJP

   G06F 8/65 20180101ALI20231109BHJP

   G06F 9/4401 20180101ALI20231109BHJP

【ＦＩ】

G06F21/57 350

G06F8/65

G06F21/57 320

G06F9/4401

【請求項の数】 9

(21)【出願番号】P 2022085651

(22)【出願日】2022-05-26

(65)【公開番号】P2023066353

(43)【公開日】2023-05-15

【審査請求日】2022-05-26

(31)【優先権主張番号】17/513,548

(32)【優先日】2021-10-28

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】508018934

【氏名又は名称】廣達電腦股▲ふん▼有限公司

【氏名又は名称原語表記】Ｑｕａｎｔａ Ｃｏｍｐｕｔｅｒ Ｉｎｃ．

【住所又は居所原語表記】Ｎｏ．１８８，Ｗｅｎｈｕａ ２ｎｄ Ｒｄ．，Ｇｕｉｓｈａｎ Ｄｉｓｔ．，Ｔａｏｙｕａｎ Ｃｉｔｙ ３３３，Ｔａｉｗａｎ

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川 裕司

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨 圭介

(72)【発明者】

【氏名】温 子恒

(72)【発明者】

【氏名】董 彦屏

(72)【発明者】

【氏名】林 威宏

【審査官】宮司 卓佳

(56)【参考文献】

【文献】特開２０１７－１７３８９３（ＪＰ，Ａ）

【文献】国際公開第２０１０／１４０６２３（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／５７

Ｇ０６Ｆ ８／６５

Ｇ０６Ｆ ９／４４０１

(57)【特許請求の範囲】

【請求項1】

コンピュータシステムにおいて、正確なファームウェアイメージの実行を確保するファームウェアイメージ検査システムであって、前記ファームウェアイメージ検査システムは、
第一プロジェクト名を有するファームウェアイメージを保存するフラッシュメモリと、
プラットフォームファームウェア回復（ＰＦＲ）ルーティンを実行するプログラム可能論理回路であって、第二プロジェクト名を保存するアクティブ領域を有する不揮発性メモリを有し、前記ファームウェアイメージの前記第一プロジェクト名と、前記不揮発性メモリに保存された前記第二プロジェクト名と、を比較し、前記第一プロジェクト名と前記第二プロジェクト名とが一致しない場合に、前記フラッシュメモリの前記ファームウェアイメージにアクセスするのを防止するプログラム可能論理回路と、
を備えることを特徴とするシステム。

【請求項2】

ベースボードマネジメントコントローラー（ＢＭＣ）をさらに備え、前記ファームウェアイメージは、ＢＭＣファームウェアイメージであることを特徴とする請求項１に記載のシステム。

【請求項3】

前記ファームウェアイメージは、基本入出力システム（ＢＩＯＳ）ファームウェアイメージであることを特徴とする請求項１に記載のシステム。

【請求項4】

前記プログラム可能論理回路は、ファームウェアアップデートの第三プロジェクト名と、保存された前記第二プロジェクト名と、を比較し、前記ファームウェアアップデートの前記第三プロジェクト名と、保存された前記第二プロジェクト名とが一致しない場合に、前記ファームウェアアップデートのローディングを防止することを特徴とする請求項１に記載のシステム。

【請求項5】

コンピュータシステムにおいて、正確なファームウェアイメージを確保するファームウェアイメージ検査方法であって、前記ファームウェアイメージ検査方法は、
プラットフォームファームウェア回復（ＰＦＲ）ルーティンを実行するプログラム可能論理回路のメモリが、第二プロジェクト名を保存する工程と、
前記プログラム可能論理回路が、保存された前記第二プロジェクト名と、ファームウェアイメージの第一プロジェクト名と、を比較する工程と、
前記プログラム可能論理回路が、保存された前記第二プロジェクト名と、前記ファームウェアイメージの前記第一プロジェクト名とが一致しない場合に、前記ファームウェアイメージにアクセスするのを防止する工程と、
を有することを特徴とする方法。

【請求項6】

前記ファームウェアイメージは、ベースボードマネジメントコントローラー（ＢＭＣ）によって実行可能なＢＭＣファームウェアイメージであることを特徴とする請求項５に記載の方法。

【請求項7】

前記ファームウェアイメージは、基本入出力システム（ＢＩＯＳ）ファームウェアイメージであることを特徴とする請求項５に記載の方法。

【請求項8】

前記プログラム可能論理回路が、ファームウェアアップデートイメージの第三プロジェクト名と、保存された前記第二プロジェクト名と、を比較する工程と、
前記第三プロジェクト名と、前記第二プロジェクト名とが一致しない場合に、前記ファームウェアアップデートイメージのローディングを防止する工程と、
をさらに有することを特徴とする請求項５に記載の方法。

【請求項9】

コンピュータシステムであって、
基本入出力システム（ＢＩＯＳ）を実行するプロセッサと、
ベースボードマネジメントコントローラー（ＢＭＣ）と、
前記プロセッサに結合された第一フラッシュメモリデバイスであって、ＢＩＯＳファームウェアイメージと、前記ＢＩＯＳファームウェアイメージの第一ＢＩＯＳプロジェクト名と、を保存する第一フラッシュメモリデバイスと、
前記ＢＭＣに結合された第二フラッシュメモリデバイスであって、ＢＭＣファームウェアイメージと、前記ＢＭＣファームウェアイメージの第一ＢＭＣプロジェクト名と、を保存する第二フラッシュメモリデバイスと、
前記第一及び第二フラッシュメモリデバイスに結合されたプログラム可能論理回路であって、第二プロジェクト名を保存する不揮発性メモリを有し、プラットフォームファームウェア回復ルーティン（ＰＦＲ）を実行して、前記ＢＭＣを起動する前に、又は、前記プロセッサが前記ＢＩＯＳファームウェアイメージを実行する前に、前記ＢＩＯＳファームウェアイメージに関連する前記第一ＢＩＯＳプロジェクト名、及び、前記ＢＭＣファームウェアイメージに関連する前記第一ＢＭＣプロジェクト名と、前記不揮発性メモリに保存された前記第二プロジェクト名と、を比較するプログラム可能論理回路と、
を備えることを特徴とするシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンピュータシステムの起動（boot-up）中の適切なファームウェアイメージの確保に関し、特に、ファームウェアプラットフォーム回復（ＦＰＲ）の実行中に、正確なファームウェアがハードウェアプラットフォーム上でアクセスされることを確保するシステムに関する。

【背景技術】

【0002】

コンピュータシステム（例えば、デスクトップコンピュータ、ブレードサーバ、ラック搭載サーバ等）は、各種アプリケーションにおいて大量に用いられている。コンピュータシステムは、一般的な計算操作を実行する。典型的なコンピュータシステム（例えば、サーバ）は、一般的に、ハードウェア素子（例えば、プロセッサ、メモリデバイス、ネットワークインターフェースカード、電源及び他の特殊なハードウェア）を有する。

【0003】

サーバは、高需要アプリケーション（例えば、ネットワークベースシステム又はデータセンター等）に大量に用いられている。クラウド計算アプリケーションの出現は、データセンターの需要を増加させている。データセンターは、大量のサーバを有しており、サーバは、データを保存するとともに、遠隔接続されたコンピュータデバイスのユーザーによりアクセスされるアプリケーションを実行する。一般的なデータセンターは、物理的なシャーシ構造を有しており、それに付随する電源及び通信接続を有する。各ラック（rack）は、複数のコンピューティングサーバ及びストレージサーバを固定することができる。個々のサーバは、複数の同一のハードウェア素子（例えば、プロセッサ、ストレージカード、ネットワークインターフェースコントローラー等）を有する。

【0004】

コンピュータシステム（例えば、サーバ）は、基本入出力システム（ＢＩＯＳ）イメージを有しており、ＢＩＯＳイメージは、通常、シリアルペリフェラルインターフェース（ＳＰＩ）ＥＥＰＲＯＭフラッシュメモリデバイスに保存され、プロセッサによって、コンピュータシステムの起動中に実行される。ＢＩＯＳは、コンピュータシステムの起動前に、ハードウェア素子からの基本的な入出力をテストするために用いられる。ＢＩＯＳファームウェア（ＢＩＯＳイメージ）は、通常、マザーボード上のフラッシュメモリデバイスに保存されている。

【0005】

また、サーバは、ベースボードマネジメントコントローラー（ＢＭＣ）を用いて、バックグラウンド処理（例えば、電力や冷却等）を管理する。ＢＭＣは、ＢＭＣによって実行されるファームウェアに従って、コンピュータシステムの操作に関するデータを様々なログに収集する。例えば、異なるハードウェア素子に関するデータは、システムイベントログ（ＳＥＬ）に保存され、ＳＥＬは、さらに、ＢＭＣファームウェアイメージと共にフラッシュメモリデバイスに書き込まれる。このように、組み込みシステムファームウェア（ＢＭＣファームウェア）は、障害の発生時にベンダーがシステム状態を分析するのに有用なシステム実行ログも保存している。このように、コンピュータシステムは、プロセッサ及びＢＭＣの基本操作のファームウェアイメージを保存するために、信頼性のある不揮発性メモリデバイス（例えば、フラッシュメモリデバイス）に依存している。

【0006】

サーバは、通常、ネットワークに接続されているので、悪意のあるユーザーは、サーバの正確な操作を阻止するために、様々な方法で攻撃を試みる。例えば、永続的なサービス拒否（ＤＯＳ）攻撃は、サーバのファームウェアを変更して、サーバの操作を阻止する。この種の攻撃は、データセンターの数日から数週間の停止時間（downtime）を生じさせるとともに、数百万のユーザーに影響する可能性がある。これらの永続的なＤＯＳ攻撃を実施する一つの方法は、攻撃者が、重要なシステム（例えば、サーバのＢＩＯＳ又はＢＭＣ）のファームウェアイメージを、エラーのあるファームウェアイメージに置き換えることである。

【0007】

永続的なＤＯＳ攻撃に対する一つの解決策は、プラットフォームファームウェア回復（ＰＦＲ）であり、これは、インテルＩｎｔｅｌ（登録商標）が提供するルーティンであり、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）で実行される。ＰＦＲは、コンピュータシステムのシステムバス上の悪意のあるトラフィックを監視し、フィルタリングする。また、ＰＦＲは、任意のファームウェアコードが実行される前に、プラットフォームファームウェアイメージのインテグリティ（integrity）を検証する。ＰＦＲは、エラーのあるファームウェアを、保護された既知のリカバリーイメージに自動的に復元する。よって、ＰＦＲは、エラーのあるファームウェアの挿入を防止し、これにより、永続的なＤＯＳ攻撃を防止する。

【0008】

ハードウェアプラットフォームの初期起動（power-on）を実行する場合、ＰＦＲは、Ｔ－１モードと呼ばれるプレブート（pre-boot）環境に移行する。Ｔ－１モードにおいて、ＰＦＲは、署名（signature）により、重要なファームウェア（例えば、ＢＭＣ及びＢＩＯＳファームウェアイメージ）に対して認証（authentication）を実行する。ＢＭＣ及びＢＩＯＳファームウェアイメージは、共に、ルートキー（root key）及びコード署名キー（ＣＳＫ）により認証された署名を有する。ルートキーは、別のキーを署名するのに用いられる認証用の主要な一定値として設計されたキーであり、全てのキーチェーン（key chain）のルートを形成する。ルートキーは、ＣＳＫにアクセスするために用いられるので、この構成は、二層の安全性を提供する。このようなキーは、ＡＷＳ等の中立的なサードパーティ（neutral third party）が有償で生成することができる。しかし、一つの問題は、ＯＥＭ（original equipment manufacturers）が、通常、各ハードウェアプラットフォーム専用のキーに対して追加料金を払うよりも、同じルートキー及びＣＳＫを、異なるハードウェアプラットフォームの複数のバージョンのハードウェアに使用することが多いことである。通常、異なるハードウェアプラットフォームの各々には、プラットフォームのＯＥＭによって、識別のための異なるプロジェクト名（project name）が与えられる。よって、特定のハードウェアプラットフォームの不正なファームウェアが、認証のために適切な署名を有することがある。同じルートキー及びＣＳＫによって署名された異なるハードウェアプラットフォームが、プラットフォーム上で不正なファームウェアイメージを用いる場合、ＰＦＲは、依然として認証の実行に成功するとともに、不正なファームウェアイメージのアクセスを許可する。しかし、不正なファームウェアイメージをローディングすると、ハードウェアプラットフォームが正常に起動できなくなることがある。また、不正なプロジェクトファームウェアイメージを用いて既存のファームウェアイメージをアップデートする場合にも、同様の結果が発生する可能性がある。

【0009】

よって、認証プロセスの間に、ＰＦＲが、正確なファームウェアを適切に識別できるようにするルーティンが必要である。また、プラットフォームのハードウェアプロビジョニング（hardware provisioning）処理の間に、ハードウェアプラットフォームのプロジェクト名をＰＦＲに提供する便利な方法が必要である。プロジェクト名を用いて、ファームウェアアップデートがハードウェアプラットフォームと正確にマッチングされることを確保することも必要である。

【発明の概要】

【発明が解決しようとする課題】

【0010】

本発明は、プラットフォームファームウェア回復実行からの起動失敗を回避する方法及びシステムを提供する。

【課題を解決するための手段】

【0011】

実施形態という用語及び同様の用語は、本開示及び以下の請求項の発明の全てに広く言及することを意図している。これらの用語を含む記述は、本明細書に記載される発明を限定するものではないし、以下の請求項の意義や範囲を限定するものでもないことを理解されたい。本明細書でカバーされる本発明の実施形態は、この概要ではなく、以下の請求項により定義される。この概要は、本開示の各種態様の高レベルの概説であり、且つ、以下の詳細な説明の段落でさらに記述されるいくつかの概念を導入する。この概要は、請求される発明の重要な必須の特徴を特定することを意図していない。この概要は、請求される発明の範囲を決定するために単独で用いられることを意図していない。発明は、本開示の明細書全体、任意の又は全ての図面及び各請求項の適切な部分を参照することにより理解されるべきである。

【0012】

開示される例は、コンピュータシステムにおける正確なファームウェアイメージの実行を確保するシステムである。システムは、プラットフォームファームウェア回復ルーティンを実行するプログラム可能論理回路を有する。プログラム可能論理回路は、プロジェクト名を保存するアクティブ領域を有する不揮発性メモリを有する。フラッシュメモリは、プロジェクト名を含むファームウェアイメージを保存する。プログラム可能論理回路は、ファームウェアイメージのプロジェクト名と、不揮発性メモリに保存されたプロジェクト名と、を比較するように構成されている。プロジェクト名が一致しない場合、プログラム可能論理回路は、フラッシュメモリ上のファームウェアイメージにアクセスするのを防止する。

【0013】

例示的システムのさらなる実施形態は、システムが、ベースボードマネジメントコントローラー（ＢＭＣ）を有し、且つ、ファームウェアイメージが、ＢＭＣファームウェアイメージである一実施形態である。別の実施形態は、プログラム可能論理回路が、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）である。別の実施形態は、ファームウェアイメージが、基本入出力システム（ＢＩＯＳ）ファームウェアイメージである。別の実施形態は、プログラム可能論理回路が、ファームウェアイメージの署名を、保存された公開キー（public key）で認証する。別の実施形態は、ファームウェアイメージのプロジェクト名が、フラッシュメモリに保存されたプラットフォームファームウェアマニフェスト（ＰＦＭ）データ構造のフィールド（field）に保存される。別の実施形態は、コンピュータシステムが最初にプロビジョニングされる（initially provisioned）場合に、プロジェクト名が不揮発性メモリに保存される。別の実施形態は、プログラム可能論理回路が、ファームウェアアップデートイメージのプロジェクト名と、保存されたプロジェクト名と、を比較し、プロジェクト名が一致しない場合に、ファームウェアアップデートイメージのローディングを防止する。

【0014】

開示される別の例は、コンピュータシステムにおいて正確なファームウェアイメージを確保する方法である。プロジェクト名は、プラットフォームファームウェア回復ルーティンを実行するプログラム可能論理回路のメモリに保存される。保存されたプロジェクト名は、ファームウェアイメージのプロジェクト名と比較される。保存されたプロジェクト名がファームウェアイメージのプロジェクト名と一致しない場合に、ファームウェアイメージへのアクセスが防止される。

【0015】

例示的な方法のさらなる実施形態は、ファームウェアイメージが、ベースボードマネジメントコントローラー（ＢＭＣ）によって実行可能なＢＭＣファームウェアイメージである一実施形態である。別の実施形態は、プログラム可能論理回路が、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）である。別の実施形態は、ファームウェアイメージが、基本入出力システム（ＢＩＯＳ）ファームウェアイメージである。別の実施形態は、方法が、プログラム可能論理回路により、保存された公開キーで、ファームウェアイメージの署名を認証する工程をさらに有する。別の実施形態は、ファームウェアイメージのプロジェクト名が、プラットフォームファームウェアマニフェストデータ構造のフィールドに保存される。別の実施形態は、方法が、コンピュータシステムのプロビジョニング処理の間にプロジェクト名を保存する工程をさらに有する。別の実施形態は、方法が、プログラム可能論理回路により、ファームウェアアップデートのプロジェクト名と、保存されたプロジェクト名と、を比較する工程をさらに有する。方法は、プロジェクト名が一致しない場合に、ファームウェアアップデートのローディングを防止する。

【0016】

開示される別の例は、基本入出力システム（ＢＩＯＳ）を実行するプロセッサと、ベースボードマネジメントコントローラー（ＢＭＣ）と、を有するコンピュータシステムである。第一フラッシュメモリデバイスは、プロセッサに結合されており、ＢＩＯＳファームウェアイメージと、ＢＩＯＳファームウェアイメージのプロジェクト名と、を保存する。第二フラッシュメモリデバイスは、ＢＭＣに結合されており、ＢＭＣファームウェアイメージと、ＢＭＣファームウェアイメージのプロジェクト名と、を保存する。プログラム可能論理回路は、第一及び第二フラッシュメモリデバイスに結合されている。プログラム可能論理回路は、プロジェクト名を保存する不揮発性メモリを有する。プログラム可能論理回路は、プラットフォームファームウェア回復ルーティンを実行して、ＢＭＣを起動する前に、又は、プロセッサがＢＩＯＳファームウェアイメージを実行する前に、ＢＩＯＳファームウェアイメージのプロジェクト名及びＢＭＣファームウェアイメージのプロジェクト名と、保存されたプロジェクト名と、を比較する。

【0017】

上記の概要は、本開示の各実施形態又は全ての態様を表すことを意図するものではない。むしろ、上述した概要は、本明細書に記載されるいくつかの新規な態様及び特徴の例を単に提供するに過ぎない。上記の特徴及び利点と他の特徴及び利点とは、添付の図面及び特許請求の範囲に関連して考慮される場合、本発明を実施するための代表的な実施形態及びモードの以下の詳細の説明から容易に明らかになるであろう。本開示の追加の態様は、以下に簡単な説明が提供される図面参照してなされる様々な実施形態の詳細な説明に照らして、当業者には明らかであろう。

【発明の効果】

【0018】

本発明により、ファームウェアプラットフォーム回復（ＦＰＲ）の実行時に、正確なファームウェアがハードウェアプラットフォーム上でアクセスされることを確保することができる。

【0019】

本開示は、添付の図面を参照して、例示的な実施形態の以下の説明からより良く理解されるであろう。これらの図面は、単に、例示的な実施形態を示すものであり、よって、各種実施形態又は請求項の範囲を限定するものと見なされるべきではない。

【図面の簡単な説明】

【0020】

【図1】本発明のある形態による、修正されたＰＦＲルーティンを組み込んで、正確なファームウェアイメージを確保するコンピュータシステムのブロック図である。

【図2】本発明のある形態による、異なるプロジェクト名を有するが、認証のキーが同じである、図１のコンピュータシステムを有する異なるプラットフォームを示す図である。

【図3】本発明のある形態による、プロジェクト名を保存するのに用いられ、ＰＦＲにアクセス可能なプラットフォームファームウェアマニフェスト（ＰＦＭ）データ構造を示す表である。

【図4】本発明のある形態による、ＢＩＯＳにより実行され、ハードウェアをセットアップするとともに、プロジェクト名をＰＦＲに提供するプロビジョンルーティンのフローチャートである。

【図5A】正確なＢＩＯＳファームウェアイメージのローディングを確保するＢＩＯＳイメージの例示的な認証ルーティンのフローチャートである。

【図5B】正確なＢＭＣファームウェアイメージのローディングを確保するＢＭＣファームウェアイメージの例示的な認証ルーティンのフローチャートである。

【図6】本発明のある形態による、アップデートされたファームウェアイメージを認証する例示的なルーティンのフローチャートである。

【発明を実施するための形態】

【0021】

添付の図面を参照して本発明を説明する。図面において、類似又は同様の要素を示すために同様の符号が用いられている。図面は、縮尺通りに示されておらず、これらは、本発明を単に例示するために提供されている。本発明のいくつかの態様を、例示的なアプリケーションを参照して以下に説明する。本発明の完全な理解を提供するために、多くの特定の詳細、関係及び方法が示されていることを理解されたい。しかし、当業者であれば、１つ以上の特定の詳細無しに又は他の方法を用いて本発明を実施することができることを容易に認識するであろう。他の例では、本発明が曖昧になるのを防ぐために、周知の構造又は動作を詳細に示していない。いくつかの動作が異なる順序で、及び／又は、他の動作や事象と同時に発生し得るので、本発明は、示された動作や事象の順序によって限定されない。さらに、本発明による方法を実施するために、示された全ての動作や事象が必要とされているわけではない。

【0022】

本発明は、多くの異なる形式で具体化される。図面に示され、且つ、ここで詳細に記述され、本発明を解釈する代表的な実施形態は、本発明の原理の例示又は説明としてみなされ、且つ、説明される実施形態の開示される広い態様を限定することを目的としていない。その程度を達成するため、例えば、要約、発明内容及び実施形態で開示されているが、請求項に明確に記載されていない要素及び限定は、単独で又は集合的に、暗示、推論又は他の方法で請求項に組み込まれるべきではない。本発明を詳細に説明する目的のため、特に断りのない限り、単数形は複数形を含み、その逆も同様である。また、「有する」という用語は「制限なしに有する」ことを意味する。さらに、近似の用語、例えば、「約（about）」、「ほとんど（almost）」、「実質的に（substantially）」、「おおよそ（approximately）」、「概ね（generally）」等の近似の用語は、ここでは、「…で（at）」、「…近くで（near）」、「…に近接して（nearly at）」、「…の３～５％内で」、「製造誤差の許容範囲内で」、又は、これらの任意の論理的組み合わせの意味を含むことができる。また、方向を示す語句、例えば、「頂部」、「底部」、「左側」、「右側」、「上方」、「下方」は、図面に示されているのと同等の方向、オブジェクト（複数可）又は要素（複数可）に対して一般的に使用される位置等から文脈的に理解できる方向、又は、本明細書に記載される方向に関するものであることを意図している。

【0023】

本発明は、特定のハードウェアプラットフォームのプロジェクト名を組み込んで、ファームウェアイメージとハードウェアプラットフォームとの互換性をチェックする修正されたプラットフォームファームウェア回復（ＰＦＲ）ルーティンに関する。例示的なＰＦＲルーティンは、プロジェクト名の確認を実行して、ＰＦＲがＴ－１段階である場合に、正確なファームウェアイメージを検証（validate）するとともに、ファームウェアをアップデートする前に、アップデートファームウェアイメージ検証を実行する。例示的なルーティンは、ＰＦＲプラットフォームが、不正なファームウェアイメージを許可して起動失敗を生じるのを防止することができ、よって、ＰＦＲにより実行されるセキュリティ機能が有効のまま維持され、適切なファームウェアが提供されることを確保する。

【0024】

図１は、ハードウェアプラットフォームの素子（例えば、コンピュータシステム１００）のブロック図であり、ＰＦＲからのルーティンを実行し、コンピュータシステム１００から、正確なファームウェアイメージのローディングを確保する。例示的なルーティンは、認証されたファームウェアイメージが、ハードウェアプラットフォームの正確なファームウェアイメージであることを確保する。この例において、コンピュータシステム１００はサーバであるが、任意の適切なコンピュータデバイスは、ここで開示される概念を組み込むことができる。コンピュータシステム１００は、二個の中央処理ユニット（ＣＰＵ）１１０，１１２を有する。二個のＣＰＵだけが示されているが、追加のＣＰＵがコンピュータシステム１００によりサポートされてもよい。専用の機能は、専用のプロセッサ（例えば、マザーボード上に搭載されたＧＰＵ、又は、コンピュータシステム１００の拡張カード（expansion card））により実行されてもよい。

【0025】

プラットフォームコントローラーハブ（ＰＣＨ）１１４は、ＣＰＵ１１０，１１２と、他のハードウェア素子（例えば、シリアルアドバンスドテクノロジーアタッチメント（ＳＡＴＡ）デバイス、オープンコンピュートプロジェクト（ＯＣＰ）デバイス及びＵＳＢデバイス）との間の通信を容易にする。ＳＡＴＡデバイスは、ハードディスクドライブ（ＨＤＤ）を有してもよい。或いは、他のメモリストレージデバイス（例えば、半導体ドライブ（ＳＳＤ））が用いられてもよい。他のハードウェア素子（例えば、ＰＣＩｅデバイス）は、拡張スロット（図示省略）を介して、ＣＰＵ１１０，１１２により直接アクセスされてもよい。追加のＰＣＩｅデバイスは、ネットワークインターフェースカード（ＮＩＣ）、レイド（redundant array of inexpensive disks、ＲＡＩＤ）カード、及び、プロセッサカード（例えば、グラフィックスプロセシングユニット（ＧＰＵ）カード）を有してもよい。ダイレクトメディアインターフェース（ＤＭＩ）バス１１６は、ＣＰＵ１１０，１１２とＰＣＨ１１４との間の通信を可能にする。

【0026】

ベースボードマネジメントコントローラー（ＢＭＣ）１２０は、コンピュータシステム１００の操作（例えば、電源管理及び温度管理）を管理する。この例において、ローピンカウント／エンハンスド（low pin count/enhanced）シリアルペリフェラルインターフェース（ＬＰＣ／ｅＳＰＩ）バス１２２は、ＰＣＨ１１４とＢＭＣ１２０との間の通信を可能にする。別のシステムマネジメント（ＳＭ）バス１２４は、ＣＰＵ１１０，１１２、ＢＭＣ１２０、及び、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）１３０間で管理コマンドを交換できるようにする。フラッシュメモリデバイス１３２は、基本入出力システム（ＢＩＯＳ）ファームウェアイメージを保存する。別のフラッシュメモリデバイス１３４は、ＢＭＣファームウェアイメージを保存する。この例において、ＰＣＨ１１４は、マルチプレクサ（multiplexer）１３８に結合されたシリアルペリフェラルインターフェース（ＳＰＩ）１３６を介して、フラッシュメモリ１３２にアクセスしてもよい。同様に、ＢＭＣ１２０は、マルチプレクサ１４２を介して、別のＳＰＩ１４０からフラッシュメモリ１３４にアクセスしてもよい。

【0027】

フラッシュメモリデバイス１３２内のブロックは、コンピュータシステム１００の起動ルーティン（start-up routine）を容易にする。ＰＣＨ１１４は、コンピュータシステム１００を起動するために、フラッシュメモリデバイス１３２に保存されたＢＩＯＳイメージのローディングを容易にする。この例において、フラッシュメモリデバイス１３４は、ＢＭＣ１２０の操作のためのＢＭＣファームウェアイメージを保存する。ＢＭＣ１２０は、ＢＭＣファームウェアイメージを実行し、ＢＭＣファームウェアイメージは、コンピュータシステム１００内のハードウェア素子の監視及び制御を可能にする。

【0028】

ＦＰＧＡ１３０は、ＰＣＨ１１４及びＢＭＣ１２０が、ＳＰＩ１３６，１４０を介して個別のフラッシュメモリ１３２，１３４にアクセスできるように、マルチプレクサ１３８，１４２を制御することができるピンを有する。この例において、ＦＰＧＡ１３０のハードウェアは、ＰＦＲルーティン１５０を実行するようにプログラミングされている。ＦＰＧＡ１３０は、ＰＦＲルーティンをサポートするデータ（例えば、コンピュータシステム１００に関連するプロジェクト名）を保存するための内部の不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）１５２を有する。この例において、フラッシュメモリ１３２，１３４の両方は、それぞれのフラッシュメモリ１３２，１３４に保存されたファームウェアイメージに関連するプロジェクト名を有するプラットフォームファームウェアマニフェスト（ＰＦＭ）構造１５４を保存する。プロビジョニング処理の間に、ＦＰＧＡ１３０のハードウェアは、ＢＩＯＳから、ルートキーハッシュ（root key hash）１５６が提供される。ルートキーハッシュ１５６は、ＮＶＲＡＭ１５２に保存される。ＣＳＫは、ルートキーによって署名され、ＰＦＲルーティンの実行中に、ファームウェア及びフラッシュメモリを認証する。

【0029】

また、ＦＰＧＡ１３０は、電源ユニット（ＰＳＵ）１６０、デジタル電圧レキュレーター（ＶＲ）１６２及びホットスワップバックプレーン（ＨＳＢＰ）１６４に結合されている。ＰＦＲルーティンからのファームウェアイメージの認証後に、ＦＰＧＡ１３０は、ＢＭＣ１２０によるこれらの素子へのアクセスを可能にする。その後、ＦＰＧＡ１３０は、コンピュータシステム１００の操作中に、ＢＭＣ１２０との間のコマンドをフィルタリングする。

【0030】

この例において、ＦＰＧＡ１３０は、ＰＦＲ１５０のファームウェアセキュリティ機能を有効にするためのルートオブトラスト（Root of Trust、ＲｏＴ）として機能する。ＲｏＴは、ＰＦＲがセキュリティ機能（例えば、未認証のコード又は設計のローディング又は実行を防止すること、ソフトウェアによって試みられる破壊的な操作を防止すること、又は、既知のバグ（buds）や脆弱性（vulnerabilities）を有する古いコード又は設計の実行を防止すること等）を実行するのをアシストする機能を有する。ＰＦＲ１５０は、コンピュータシステム１００の安全な操作を提供するために、ＢＭＣ１２０が認証を取り消すことを可能にする。

【0031】

この例において、ＦＰＧＡ１３０は、保存されたファームウェアイメージを認証し、エラーのあるファームウェアイメージがシステム１００にダウンロードされることを防止するという目的のために、ＰＦＲ１５０を実行する。この例において、ＦＰＧＡ１３０は、ＰＦＲ１５０を実行するように特別にプログラミングされたＩｎｔｅｌ Ｍａｘ １０ ＦＰＧＡである。しかし、任意のプログラム可能コントローラー又は他のＦＰＧＡが、セキュリティ機能を実行するために用いられてもよい。

【0032】

この例において、パブリック（公開）及びプライベート（秘密）ルートキーと、ＣＳＫとは、サードパーティーベンダー（例えば、ＡＷＳ）により生成される。或いは、キーは、ハードウェアセキュリティモジュール（ＨＳＭ）又はＯｐｅｎＳＳＬを用いて生成されてもよい。キーのうち一つは、ルートキーとして設計され、別のキーは、コード署名キー（ＣＳＫ）として設計される。これらのキーは、非対称キーであり、それらが、パブリック及びプライベートキーの潜在的なペア（underlying pair）で形成されることを意味する。ＣＳＫキーは、例えばファームウェアイメージ等のオブジェクトに対して署名を生成し、ファームウェアイメージは、ハードウェアプラットフォームの製造者により分配され、ルートキーによって署名された対応するＣＳＫキーで検証することができる。

【0033】

図２は、ＯＥＭによって製造されるハードウェアプラットフォームのシリーズを示す図である。この例において、ＯＥＭは、各ハードウェアプラットフォームに対して異なるプロジェクト名を指定している。よって、コンピュータシステム１００は、１２個の拡張カードを有し、指定されたプロジェクト名が「緑色」である、第一ハードウェアプラットフォームである。第二ハードウェアプラットフォーム２１０は、１０個の拡張カードを有し、指定されたプロジェクト名が「青色」である。第三ハードウェアプラットフォーム２２０は、１２個の拡張カードを有し、指定されたプロジェクト名が「茶色」である。第四ハードウェアプラットフォーム２３０は、２０個の拡張カードを有し、指定されたプロジェクト名が「黄色」である。図２の各ハードウェアプラットフォームは、同じルートキー及びＣＳＫを有しており、既知のＰＦＲを実行する個別のＦＰＧＡにより認証を実行する。しかし、異なるプラットフォーム１００，２１０，２２０，２３０の全てのファームウェアイメージが同じ署名を有するので、不正なファームウェアイメージが認証及びロードされる可能性がある。例えば、ハードウェアプラットフォーム２１０のファームウェアイメージが、ハードウェアプラットフォーム２３０に誤ってロードされる可能性がある。このようなファームウェアイメージは、適切な署名を有するが、ハードウェアプラットフォーム２３０と互換性がないので、起動時にハードウェアプラットフォーム２３０をクラッシュさせる可能性がある。

【0034】

コンピュータシステム１００において、ルートキー及びＣＳＫの公開キーは、秘密（private）キーを排他的に所有するＯＥＭによって署名を生成するために使用される。署名は、フラッシュメモリ１３４に保存されたＢＭＣファームウェアイメージと、フラッシュメモリ１３２に保存されたＢＩＯＳファームウェアイメージと、任意の他のファームウェアイメージと、に対して生成される。上述したように、ＦＰＧＡ１３０は、ルートキーハッシュ１５６を保存する。ルートキーハッシュ１５６は、ＣＳＫを署名して、任意のファームウェアイメージの署名を認証するために用いられる。この例において、ＰＦＲ１５０は、ハードウェアプラットフォームのプロビジョニングルーティンからプロビジョニングデータを受信する。プロビジョニングデータは、プロジェクト名を有する。

【0035】

プロビジョニングの後に、ＢＭＣ及びＢＩＯＳファームウェア構築プロセスが実行される。このプロセスの間、プラットフォームファームウェアマニフェスト（ＰＦＭ）データ構造１５４が生成され、フラッシュメモリ１３２，１３４に保存される。データ値が、ファームウェアイメージを保存するフラッシュメモリ内のＰＦＭデータ構造１５４に保存される。例えば、フラッシュメモリ１３２に保存されるＰＦＭデータ構造１５４は、フラッシュメモリ１３２に保存されるＢＩＯＳイメージに関連するプロジェクト名データを有する。同様に、フラッシュメモリ１３４に保存されるＰＦＭデータ構造１５４は、フラッシュメモリ１３４に保存されるＢＭＣファームウェアイメージに関連するプロジェクト名データを有する。この例において、対応するファームウェアイメージが正確である場合、ＰＦＭデータ構造１５４は、ハードウェアプラットフォーム（コンピュータシステム１００）に固有のプロジェクト名（例えば、「緑色」）を含むはずである。

【0036】

ＮＶＲＡＭ１５２に保存されたプロジェクト名は、保存されたファームウェアイメージに関連するＰＦＭデータ構造１５４に保存されたプロジェクト名が、ハードウェアプラットフォームに対して正確であるか否かを、ＰＦＲ１５０が確認するために用いられる。図３は、例示的なルーティンにより用いられる図１のＰＦＭデータ構造１５４を示す表３００である。ＰＦＭデータ構造１５４の表３００は、タグフィールド３１０と、セキュリティバージョンナンバーフィールド３１２と、最もよく知られた構成（best known configuration、ＢＫＣ）バージョンフィールド３１４と、ＰＦＭ補正フィールド（PFM revision）３１６と、保留（reserved）フィールド３１８と、ＯＥＭ特別データ（OEM specific data）フィールド３２０と、長さフィールド３２２と、ＰＦＭ本体（PFM body）フィールド３２４と、パッド（padding）フィールド３２６と、を有する。ＢＭＣ及びＢＩＯＳファームウェア構築プロセス中に、ＰＦＭデータ構造１５４のフィールドの値がデータ構造１５４に書き込まれる。この例において、ＯＥＭ特別データフィールド３２０は、ハードウェアプラットフォームのＯＥＭによって指定されたプロジェクト名を有する。よって、プロジェクト名「緑色」が、コンピュータシステム１００のデータフィールド３２０に書き込まれて、コンピュータシステム１００に関連するファームウェアイメージに使用される。

【0037】

プロビジョニング処理後に、ＰＦＲ１５０は、ハードウェアプラットフォーム（例えば、コンピュータシステム１００）の起動中に、ＦＰＧＡ１３０によって実行される。ＰＦＲ１５０がＴ－１段階になると、ＰＦＲ１５０は、図１のフラッシュメモリ１３２，１３４にアクセスして、ルートキー及びＣＳＫペアの公開キーから生成された署名を認証することにより、各フラッシュメモリ１３２，１３４のアクティブ（active）領域及びリカバリー（recovery）領域の認証を実行する。認証が成功した場合に、全てのファームウェアイメージがフラッシュメモリ１３２，１３４からロードされる。この例において、ＰＦＲ１５０は、ファームウェアイメージのローディングを許可する前に、ファームウェアイメージに関連するプロジェクト名を検証する。このプロジェクト名は、フラッシュメモリのアクティブ領域内のＰＦＭデータ構造１５４のＯＥＭ特別データフィールドに保存されている。ＰＦＭデータ構造１５４からのファームウェアイメージのプロジェクト名が、ＮＶＲＡＭ１５２に保存されたプロジェクト名と一致する場合には、ファームウェアイメージが正確であるので、ＰＦＲ１５０は、コンピュータシステム１００の認証ルーティンを継続する。ファームウェアイメージのプロジェクト名が、ＮＶＲＡＭ１５２に保存されたプロジェクト名と一致しない場合には、ＰＦＲ１５０は、不正なファームウェアイメージを保存する個別のフラッシュメモリへのアクセスを阻止するとともに、オペレーティングシステムがブートするのを防止する。

【0038】

同様に、ファームウェアイメージをアップデートする場合、ＢＭＣ１２０又はＢＩＯＳは、それぞれのファームウェアイメージをアップデートするための要求を送信する。ＦＰＧＡ１３０は、要求を受信すると、アップデートされたファームウェアイメージを認証する。ＰＦＲ１５０は、フラッシュメモリと、アップデートされたファームウェアイメージと、を認証する。また、ＰＦＲ１５０は、アップデートされたファームウェアイメージに関連するプロジェクト名と、ＮＶＲＡＭ１５２に保存されたプロジェクト名と、を検証する。プロジェクト名が正確である場合、ＰＦＲ１５０は、アップデートフローを続行し、アップデートされたファームウェアイメージがフラッシュメモリ内でアクセスされるのを許可する。プロジェクト名が正確でない場合、ＰＦＲ１５０は、このアップデートを拒否する。このようにして、例示的なルーティンは、正確なファームウェアイメージがロードされて、コンピュータシステム１００を正確に操作するよう確保する。

【0039】

図４は、図１のＰＦＭデータ構造１５４にプロジェクト名を書き込むプロビジョニング処理のフロー図である。ＢＩＯＳは、プレブート実行環境（pre-boot execution environment、ＰＸＥ）ルーティンにより、プロビジョニング処理を初期化する（４１０）。ＰＸＥにより、外部のサーバとの通信が確立される（４１２）。ハードウェアプラットフォーム上の素子をプロビジョニングするためのテンプレートがロードされる（４１４）。ルートキーハッシュ１５６と、アクティブ、リカバリー及びステージング領域（staging region）のＳＰＩオフセット（offset）と、プロジェクト名とが、ＢＩＯＳによって受信される（４１６）。ＢＩＯＳは、ＳＰＩオフセットを用いて、アクティブ、リカバリー及びステージング領域のフラッシュメモリ内の位置を決定する。ＢＩＯＳは、ルートキーハッシュ１５６と、アクティブ、リカバリー及びステージング領域のＳＰＩオフセットと、プロジェクト名とを、ＦＰＧＡ１３０に送信する（４１８）。そして、ＰＦＲ１５０は、ルートキーハッシュ１５６と、アクティブ、リカバリー及びステージング領域のＳＰＩオフセットと、プロジェクト名とを保存する（４２０）。この例において、ルートキーハッシュ１５６は、ＦＰＧＡ１３０内でプログラミングされ、ルートキーハッシュ１５６と、アクティブ、リカバリー及びステージング領域のＳＰＩオフセットと、プロジェクト名とが、ＮＶＲＡＭ１５２に保存される。

【0040】

図５Ａは、ハードウェアプラットフォームに関連するプロジェクト名を用いて、ＢＩＯＳファームウェアイメージを認証するＰＦＲルーティンを示す図である。図１のＰＦＲ１５０は、先ず、ＢＭＣ１２０及びＢＩＯＳがリセットされないように保持する（５１０）。ＰＦＲ１５０は、ＮＶＲＡＭ１５２に保存されたプロジェクト名に対する指標（pointer）を読み取って、保存されたプロジェクト名を読み取るとともに、フラッシュメモリ１３２内のＰＦＭデータ構造１５４に保存されたプロジェクト名を読み取る（５１２）。そして、ＰＦＲ１５０は、保存されたプロジェクト名と、フラッシュメモリ１３２内のＰＦＭデータ構造１５４に保存されたＢＩＯＳファームウェアイメージのプロジェクト名と、を比較する。ＰＦＲ１５０は、ＢＩＯＳファームウェアイメージのプロジェクト名が、保存されたプロジェクト名と一致するか否かを判断することにより、プロジェクト名が正確であるか否かを判断する（５１４）。ＢＩＯＳファームウェアイメージのプロジェクト名が正確でない場合、ＰＦＲ１５０は、起動を停止する（５１６）。プロジェクト名が正確である場合、ＰＦＲ１５０は、ＢＩＯＳファームウェアイメージの署名を読み取る（５１８）。ＰＦＲ１５０は、ルートキーハッシュ１５６を用いて、ＢＩＯＳファームウェアイメージの署名が認証済みか否か判断する（５２０）。署名が認証済みでない場合（５２０）、ＰＦＲ１５０は、フラッシュメモリ１３２へのアクセスを防止するとともに、起動を防止する（５１６）。署名がルートキーハッシュから認証される場合、ＰＦＲ１５０は、ＢＩＯＳをリリースするとともに、ＢＩＯＳをリセットして、起動プロセスを開始させる（５２２）。

【0041】

図５Ｂは、ハードウェアプラットフォームに関連するプロジェクト名を用いて、ＢＭＣファームウェアイメージを認証するＰＦＲルーティンを示す図である。図１のＰＦＲ１５０は、先ず、ＢＭＣ１２０及びＢＩＯＳがリセットされないように保持する（５５０）。ＰＦＲ１５０は、ＮＶＲＡＭ１５２に保存されたプロジェクト名に対する指標を読み取って、保存されたプロジェクト名を読み取るとともに、フラッシュメモリ１３４内のＰＦＭデータ構造１５４に保存されたプロジェクト名を読み取る（５２２）。そして、ＰＦＲ１５０は、保存されたプロジェクト名と、フラッシュメモリ１３４のＰＦＭデータ構造１５４に保存されたＢＭＣファームウェアイメージのプロジェクト名と、を比較する。ＰＦＲ１５０は、ＢＭＣファームウェアイメージのプロジェクト名が、保存されたプロジェクト名と一致するか否かを判断することにより、プロジェクト名が正確であるか否かを判断する（５５４）。ＢＭＣファームウェアイメージのプロジェクト名が正確でない場合、ＰＦＲ１５０は、ＢＭＣ１２０の起動を停止する（５５６）。プロジェクト名が正しい場合、ＰＦＲ１５０は、ＢＭＣファームウェアイメージの署名を読み取る（５５８）。ＰＦＲ１５０は、ルートキーハッシュ１５６を用いて、ＢＭＣファームウェアイメージの署名が認証済みであるか否かを判断する（５６０）。署名が認証済みでない場合（５６０）、ＰＦＲは、フラッシュメモリ１３４へのアクセスを防止すると共に、起動を防止する（５５６）。署名が、ルートキーハッシュから認証済みである場合、ＰＦＲ１５０は、ＢＩＯＳをリリースするとともに、ＢＭＣ１２０をリリースして、起動プロセスを開始させる（５６２）。

【0042】

図６は、図１のＰＦＲ１５０を実行して、プロジェクト名にアクセスして、適切なシステム操作を確保することにより、ファームウェアイメージをアップデートするルーティンを示す図である。ＰＦＲ１５０は、外部のアップデートされたファームウェアイメージのために図１のフラッシュメモリ１３２又は１３４の何れかにアクセスするための、ＢＭＣ１２０又はＢＩＯＳによる要求を受信する（６１０）。ＰＦＲ１５０は、ルートキーハッシュ１５６を用いて、受信したアップデートファームウェアイメージの署名を認証する（６１２）。ＰＦＲ１５０は、アップデートファームウェアイメージの署名が認証済みか否かを判断する（６１４）。アップデートファームウェアイメージが認証済みでない場合（６１４）、ＰＦＲ１５０は、拒絶ファームウェアの信号を返送するとともに、ファームウェアイメージアップデートのローディングを防止する（６１６）。認証が成功した場合、ＰＦＲ１５０は、プロジェクト名の指標を読み取って、ＮＶＲＡＭ１５２からプロジェクト名を読み取る（６１８）。ＰＦＲ１５０は、ＮＶＲＡＭ１５２から、保存されたプロジェクト名を読み取るとともに、それを、受信したファームウェアイメージのプロジェクト名と比較して、ファームウェアイメージのプロジェクト名が正確であるか否かを判断する（６２０）。プロジェクト名が正確である場合、ＰＦＲ１５０は、アップデートフローを続行する（６２２）。プロジェクト名が正確でない場合、ＰＦＲ１５０は、拒絶ファームウェアの信号を返送するとともに、ファームウェアイメージアップデートのローディングを防止する（６１６）。

【0043】

図４～図６の上述したルーティンは、ＢＩＯＳに、図２のＦＰＧＡ１３０にプロジェクト名を供給させるとともに、ファームウェアイメージ又はアップデートされたファームウェアイメージをチェックさせて、適切なファームウェアが、コンピュータシステムのためにアクセスされることを確保するための例示的な機械可読命令を示す。この例において、機械可読命令は、（ａ）プロセッサ、（ｂ）コントローラー、及び／又は、（ｃ）一つ以上の他の適切な処理装置によって実行されるアルゴリズムを有する。アルゴリズムは、有形媒体（例えば、フラッシュメモリ、ＣＤ－ＲＯＭ、フロッピー（登録商標）ディスク、ハードドライブ、デジタルビデオ（versatile）ディスク（ＤＶＤ）、又は、他のメモリデバイス等）に記憶されたソフトウェアで具体化される。しかし、当業者であれば、アルゴリズム全体及び／又はそれらの一部は、プロセッサ以外の装置によって実行され、及び／又は、ファームウェア又は専用のハードウェアにおいて既知の方法で具体化される（例えば、特定用途向け集積回路（ＡＳＩＣ）、プログラム可能論理回路（ＰＬＤ）、フィールドプログラム可能論理回路（ＦＰＬＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、個別論理装置等により実施される）ことを容易に理解するであろう。例えば、ルーティンの任意の又は全ての要素は、ソフトウェア、ハードウェア及び／又はファームウェアにより実行される。また、フローチャートにより示される機械可読命令の一部又は全ては、手動で実施され得る。さらに、例示的なルーティンがここで開示されるが、当業者であれば、例示的な機械可読命令を実行する多くの他の方法が代わりに用いられてもよいことを容易に理解することができる。

【0044】

開示された実施形態は、一つ以上の実施形態に関して図示及び説明されているが、当業者であれば、本明細書及び図面を読み、理解した後に、同等の変更及び修正を思いつくであろう。さらに、本発明の特定の特徴は、いくつかの実施形態のうち何れかのみに関して開示されているが、このような特徴は、任意の又は特定の応用に対して所望され有利である場合に、別の実施形態の一つ以上の別の特徴と組み合わされてもよい。

【0045】

本発明の各種実施形態が上述されているが、これらは、例として表現されており、これに限定されないことを理解されたい。開示された実施形態に対する様々な変更を、本発明の範囲と趣旨を逸脱しない状況下で行うことができる。よって、本発明の広さや範囲は、上述した何れかの実施形態によって限定されるべきではない。むしろ、本発明の範囲は、以下の請求項及びそれらの均等物に従って定義されるべきである。

【符号の説明】

【0046】

１００…コンピュータシステム
１１０、１１２…中央処理ユニット（ＣＰＵ）
１１４…プラットフォームコントローラーハブ（ＰＣＨ）
１１６…ダイレクトメディアインターフェース（ＤＭＩ）バス
１２０…ベースボードマネジメントコントローラー（ＢＭＣ）
１２２…ローピンカウント／エンハンスド（low pin count/enhanced）シリアルペリフェラルインターフェース（ＬＰＣ／ｅＳＰＩ）
１２４…システムマネジメント（ＳＭ）バス
１３０…フィールドプログラマブルゲートアレイ（ＦＰＧＡ）
１３２、１３４…フラッシュメモリデバイス
１３６、１４０…シリアルペリフェラルインターフェース（ＳＰＩ）
１３８、１４２…マルチプレクサ
１５０…プラットフォームファームウェア回復（ＰＦＲ）
１５２…不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）
１５４…プラットフォームファームウェアマニフェスト（ＰＦＭ）データ構造
１５６…ルートキーハッシュ
１６０…電源ユニット（ＰＳＵ）
１６２…デジタル電圧レキュレーター（ＶＲ）
１６４…ホットスワップバックプレーン（ＨＳＢＰ）
２１０…第二ハードウェアプラットフォーム
２２０…第三ハードウェアプラットフォーム
２３０…第四ハードウェアプラットフォーム
３００…表
３１０…タグ（tag）フィールド
３１２…セキュリティバージョンナンバーフィールド
３１４…最もよく知られた構成（best known configuration、ＢＫＣ）バージョンフィールド
３１６…ＰＦＭ補正フィールド
３１８…保留フィールド
３２０…ＯＥＭ特別データフィールド
３２２…長さフィールド
３２４…ＰＦＭ本体フィールド
３２６…パッド（padding）フィールド
４１０、４１２、４１４、４１６、４１８、４２０、５１０、５１２、５１４、５１６、５１８、５２０、５２２、５５０、５１２、５１４、５１６、５１８、５２０、５２２、５５０、５５２、５５４、５５６、５５８、５６０、５６２、６１０、６１２、６１４、６１８、６２０、６２２…工程

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6】