信頼された実行環境の ACPI プロファイル
ライセンス: Microsoft は、本仕様の実装の作成、使用、販売、販売申出、輸入、または配布のみを目的として、合理的かつ非差別的な条件で、「必要な請求」に対して無償 (無料) のライセンスをお客様に付与することに同意します。 「必要な要求」とは、この仕様の必須部分 (オプション部分の必須要素も含む) を実装するために技術的に必要な、Microsoft 所有またはマイクロソフトによって制御された特許の要求のことです。この仕様では、侵害の原因となっている機能が詳細に説明されています。
1.0 背景
この仕様では、TPM 2.0 デバイスの ACPI デバイスオブジェクトと、Windows 8 に必要な ACPI デバイスオブジェクトに関連付けられているコントロールメソッドを定義します。 コントロールメソッドは、TCG 物理プレゼンス ACPI インターフェイスと同等のものを実装します。これはプラットフォームリセット攻撃の緩和インターフェイスに相当し、オプションで、TPM 2.0 デバイスにコマンドを送信するための ACPI メソッドです。
TPM 2.0 デバイスと Windows 8 OS の間で通信するためのメカニズムを定義するために、追加の静的 ACPI テーブル (TPM2) が使用されます。
Note
Microsoft は、Trusted Computing Group の「TPM」を参照しています。次の「用語 (TPM 2.0)」
2.0 要件
この仕様は、OS とファームウェア環境の間で [ACPI09] で指定されている ACPI ベースの通信をサポートするコンピューティングプラットフォームを前提としています。
3.0 使用シナリオ (例のみ)
3.1 物理プレゼンスコマンドを送信する
一般的な使用シナリオは次のとおりです:
OS 環境内で、アプリケーションは、Windows 8 用に完全にプロビジョニングされていない TPM 2.0 デバイスを検出します。 (このような状況の例として、以前の OS イメージが TPM 2.0 をプロビジョニングした後に新しい OS イメージがインストールされた場合など)。
アプリケーションは OS ウィザードを起動して、TPM 2.0 デバイスの使用を準備します。
ウィザードは UI を介してコンピューター管理者と対話し、TPM 2.0 デバイスリセットロックアウトの認証値が使用できないため、管理者が TPM 2.0 デバイスをクリアしてプロビジョニングする必要があると判断します。
TPM 2.0 デバイスをクリアするには (TPM 2.0 デバイスオブジェクトの ACPI 制御方法を実行することによって)、物理的に存在するユーザーが TPM 2.0 デバイスのクリアを承認していることを確認するために、ファームウェアは次のブート時に TPM 2.0 デバイスをクリアする操作を実行します。
OS によってプラットフォームが再起動されます。
ブートプロセスの初期段階では、OS からの保留中の要求がファームウェアによって認識され、TPM 2.0 デバイスがクリアされます。
ファームウェアは、TPM 2.0 デバイスのクリアを確認する何らかのアクションを実行するように求める、物理的に存在するユーザーに UI を提示します。
物理的に存在するユーザーが、TPM 2.0 デバイスのクリアを確認します。
ファームウェアは、platform hierarchy authorization を使用して TPM 2.0 デバイスをクリアします。
必要に応じて、TPM 2.0 デバイスのクリアを永続化するために、プラットフォームが直ちに再起動されます。
OS が起動します。
TPM 2.0 デバイスをクリアする最後の OS 要求が (a) 成功した場合 (a)、物理的に存在するユーザーによって (b) が確認されなかった場合、または (c) 他のエラーが発生した場合は、(TPM 2.0 デバイスの ACPI 制御方式を使用して) OS クエリが実行されます。 次の例では、TPM 2.0 デバイスが正常にクリアされたことを前提としています。
OS 内の TPM 2.0 デバイスプロビジョニングウィザードでは、Windows で使用できるようにデバイスを準備するための追加のコマンドを実行します。
}3.2 次回の起動時にクリアされるメモリを要求する
このシナリオでは、プラットフォームが予期せず再起動された後にシステムメモリを収集する攻撃をシステムのメモリ消去機能で阻止する方法について説明します。
OS 内から、TPM 2.0 デバイスが搭載されたシステムの管理者は、OS ボリュームの BitLocker 機能をオンにします。
BitLocker 機能は、TPM 2.0 デバイス ACPI 制御メソッドを呼び出して、TCG プラットフォームリセット攻撃の緩和の仕様で定義されている ClearMemory ビットを設定します。
BitLocker 機能によって、OS ボリュームが暗号化されます。
管理者は、画面がロックされた状態でシステムを無人状態のままにします。
悪意のあるユーザーが、実行中にシステムを盗みます。
悪意のある人物が USB スティックを挿入し、システムのバッテリをすぐに削除して、再挿入します。
バッテリが再挿入されると、システムが起動を開始します。
ClearMemory ビットが以前に設定されていたため、プラットフォームの製造元によって提供されていないコードを起動する前に、ファームウェアはシステムメモリ全体をクリアします。
悪意のあるユーザーが、USBデバイス上のコードが適切に署名されていない場合でも、ブート時にファームウェアを USB デバイスで起動するように構成します。
USB デバイスのコードは、BitLocker ボリュームマスターキーのシステムメモリをスキャンしますが、検出されません。
警告
手順 11. から 16. は、前の手順と似ていますが、ACPI ではなく UEFI インターフェイスを使用します。
悪意のあるユーザーがシステムを正常に起動しようとしています。
BitLocker は TPM キー保護機能を使用して有効にされているため、bootmgr の実行時に、正しい測定値が TPM 2.0 デバイスに存在するため、BootMgr は OS ボリュームのボリュームマスターキーを "封印" することができます。
ブートは OS のログオン画面に進みます。
悪意のあるユーザーがもう一度バッテリを削除し、USB デバイスからコードを起動します。
ClearMemory ビットが設定されているため、システムファームウェアはブート中にシステムメモリ全体を消去します。
USB デバイスのコードがシステムメモリをスキャンする場合でも、OS ボリューム暗号化キーはメモリ内にありません。
3.3 TPM 2.0 デバイスへのコマンドの発行
この例は、すべてのシステムアーキテクチャに適用できるわけではありません。
Windows TPM 2.0 ドライバーは、TPM 2.0 デバイスにコマンドを発行しようとしています。
Windows TPM 2.0 ドライバーは、Windows TPM 2.0 ドライバーの初期化中に、ACPI によって定義されたコントロール領域から読み取られた物理アドレスに実行するコマンドを書き込みます。
Windows TPM 2.0 ドライバーは、TPM 2.0 コマンドを実行するための ACPI コントロールメソッドを実行します。
Windows TPM 2.0 ドライバーは、TPM コマンドが完了したことを示すまで、コントロール領域のレジスタをポーリングします。
Windows TPM 2.0 ドライバーは、Windows TPM 2.0 ドライバーの初期化中に、ACPI によって定義されたコントロール領域から読み取られた物理アドレスに実行するコマンドを書き込みます。
}4.0 TPM 2.0 システムおよびデバイスの一般的な ACPI 要件
4.1電源に関する考慮事項
ACPI D1/D2
TPM 2.0 デバイスは ACPI D1 または ACPI D2 をサポートする場合がありますが、D1 または D2 で、電源状態が ACPI D0 の場合と同様に動作する必要があります。
ACPI S3 (スリープ)
TPM 2.0 は S3 をサポートする場合がありますが、デバイスの S3 低電力状態からの入力と終了は、システム/プラットフォーム製造元によって制御される必要があります。
OS (または OS 環境で実行されているその他のソフトウェア) では、TPM 2.0 デバイスを S3 に配置できないか、または TPM 2.0 デバイスが S3 から終了する必要があります。 たとえば、TPM 2.0 デバイスがバス上にある場合、OS は、TPM 2.0 デバイスが S3 に入る原因となるバスの電源を切ることができないようにする必要があります。
Windows 8 TPM ドライバーは、S3 (スリープ) に入る前に TPM2_Shutdown コマンドを発行しようとします。
ハードウェアプラットフォームで S3 がサポートされていて、システムが S3 の間、TPM がその状態を保持していない場合、プラットフォームは S3 の再開中に必要な TPM2_Init と TPM2_Startup (TPM_SU_STATE) コマンドを発行する必要があります。 S3 に入る前に、OS が TPM2_Shutdown コマンドを完了していない可能性があります。 これにより、TPM2_Startup (TPM_SU_STATE) の戻り結果がエラーを返す可能性があります。 S3 から再開するシステムファームウェアは、TPM2_Startup エラーを適切に処理する必要があります。 たとえば、ハードウェア経由で TPM へのアクセスを無効にするか、TPM2_Startup (TPM_SU_CLEAR) コマンドを発行し、エラーダイジェスト (0x01) を使用して区切り記号を Pcr 0 から 7 に拡張し、NV インデックスをロックするなどの操作を行って、デバイスを安全に構成します。
システムは、システムがロックアウト間隔 (TPM_PT_LOCKOUT_INTERVAL) に対して S3 である時間について、TPM 辞書攻撃の失敗回数 (TPM_PT_LOCKOUT_COUNTER) をデクリメントすることで、S3 の経過時間を考慮する必要があります。 これには、S3 の間に TPM クロックや状態を維持するためにスタンバイ電圧を提供するプラットフォームの実装が必要になる場合があります。また、プラットフォームが低電力状態である間の経過時間に関する情報をセキュリティで保護することもできます。これにより、TPM は辞書攻撃ロジックの承認エラー数を確実に更新できます
コネクトスタンバイシステムの低電力状態
Windows 8 は、接続されたスタンバイシステムの低電力状態での入力時および終了時に、TPM に関連付けられている追加の操作を実行しません。 システムが接続されたスタンバイシステムの低電力状態に出入りするたびに、TPM が D0 のように動作するために必要なアクションを実行する必要があります。 このためには、TPM クロックの電源を入れたり、状態を保持したりするために、プラットフォームの実装が必要になる場合があります。 また、プラットフォームでは、システムの電力が不足している間の経過時間に関する情報を TPM に安全に提供する必要がある場合があります。そのため、TPM は、その辞書攻撃ロジックに対して承認エラー数を確実に更新できます。
システムオフ
システムは、システムがロックアウト間隔 (TPM_PT_LOCKOUT_INTERVAL) に対して S5 である時間について、TPM 辞書攻撃の失敗回数 (TPM_PT_LOCKOUT_COUNTER) をデクリメントすることで、S5 の経過時間を考慮する必要があります。
4.2 ACPI テーブル
TPM 2.0 デバイスを搭載したシステムでは、次に示すように、ハードウェアデバイス ID と OS ベンダー固有の静的テーブル (TPM2) を持つデバイスオブジェクトテーブルを提供する必要があります。
プラットフォームが顧客に発送されたら、TPM2 テーブルと TPM 2.0 デバイスオブジェクトの両方を永続的にする必要があります。 (たとえば、ファームウェア オプションは、TPM2 テーブルまたは TPM 2.0 デバイス オブジェクトの非表示を許可してはなりません。例外は、TPM 2.0 機能の代わりに TPM 1.2 機能を提供する既定以外のオプションがシステムに付属している場合です (つまり、Windows 7 などの古いオペレーティング システムとの互換性のため)。このような状況では、TPM2 テーブルと TPM 2.0 デバイス オブジェクトは、実行された TPM 1.2 の BIOS 構成オプションと列挙を使用して削除される場合があります。 注意: 既定では、TPM 2.0 がオペレーティングシステムに表示されているので、Windows 8 用のコネクトスタンバイシステムが出荷される必要があります。 ハードウェアプラットフォームでの TPM 2.0 と TPM 1.2 の切り替えに関する技術ガイダンスについては、Microsoft にお問い合わせください。
4.3 TPM 2.0 デバイスオブジェクト ACPI テーブル
4.3.1Bus階層
デバイスオブジェクトテーブルは、ACPI 名前空間の DSDT テーブルの下にある必要があります。TPM 2.0 デバイスオブジェクトは、システムバスの "root \ _SB" に配置されている必要があります。
4.3.2 ハードウェア識別子
TPM 2.0 デバイスオブジェクトの実際のプラグアンドプレイハードウェア識別子 (_HID など) は "MSFT0101" である必要があります。また、デバイスには互換性のある ID "MSFT0101 _HID" が含まれている必要があり、ベンダー固有のものである可能性があります。
4.3.3 リソース記述子
ACPI TPM 2.0 デバイスオブジェクトは、TPM 2.0 デバイスによって使用されているすべてのリソースを要求する必要があります。
4.3.4ACPI 制御メソッド
4.3.4.1 Platform Reset 攻撃の緩和
システムは、UEFI 用の [TCG08] のすべての ACPI および UEFI 関連の部分を実装する必要があります。 デバイスオブジェクトは、[TCG08] のセクション6で定義されているコントロールメソッドインターフェイスを実装する必要があります。 プラットフォームがすべてのブートでメモリを無条件でクリアする場合でも、インターフェイスは必須です。 TPM 2.0 デバイスの状態では、メモリのクリアが条件にならないようにする必要があります (これに対して、TPM 1.2 が所有されていない場合、[TCG08] はメモリのクリアを必要としません)。 また、セクション3、[TCG08] の5つを実装する必要があります。 この_DSMのクエリ関数は ACPI 仕様に基づいて( 関数インデックス 0) を実装する必要があります。 (注: _DSM メソッドの戻り値に関する ACPI 4.0 仕様に間違いがあります。_DSM メソッドの戻り値は、0x03を含むバッファーである必要があります)。実装では、整然と OS シャットダウンを自動検出し、このようなイベントの ClearMemory ビットをクリアする必要があります。
TPM 2.0 を搭載した UEFI ベースの Arm システムの特別な注意: TPM 2.0 を搭載した UEFI ベースの Arm システムでは、Windows 8は、すべてのブートで UEFI インターフェイスを使用して無条件にメモリのクリアを要求します。 ACPI インターフェイスの実装は依然として必要ですが、ClearMemory または DisableAutoDetect 検出フラグの状態を変更しないようにインターフェイスを実装することもできます。 (注意: ACPI インターフェイスを呼び出すと ClearMemory または DisableAutoDetect 検出の状態が変わるように、TCG 仕様に従って ACPI インターフェイスを実装することをお勧めします)。
4.3.4.2物理プレゼンス インターフェイス
システムは、次の追加のメモに従って、[TCG11] で定義されている仕様を実装する必要があります。
TCG 仕様での TPM の使用は、TPM 2.0 デバイスと同じにしてください。
セクション 2 で定義されている制御メソッドは、次の制限を使用して実装する必要があります:
この_DSMのクエリ関数は ACPI 仕様に基づいて( 関数インデックス 0) を実装する必要があります。 (注: _DSM メソッドの戻り値に関する ACPI 4.0 仕様に間違いがあります。_DSM メソッドの戻り値は、0x01FFを含むバッファーである必要があります)。
実装では、"Get Platform-Specific Action to Transition to Pre-OS Environment" の値 "2: Reboot" を返す必要があります。再起動の切り替えには PPI 操作を実行する必要があります。シャットダウン遷移では SHOULD を実行する必要があります。
次の制御メソッドの実装は省略可能です:"SUBMIT TPM Operation Request to Pre-OS Environment" ("2: General Failure" を返す場合があります) と "Submit preferred user language" (推奨ユーザー言語の送信) ("3: 実装されていません" を返す場合があります)。
セクション 3 の要件は、次のリビジョンで実装する必要があります:
承認する操作は TPM 2.0 デバイスの状態には関係ないので、BIOS は NoPPIProvision フラグに永続的なストレージを提供する必要はありません。
表2は以下のように改訂されています:
表 1: PPI テーブル 2 の改訂
OperationValue
操作の名前
TPM Stat
BIOS TPM Mgmt Flags
任意でMandatory versus
物理的なプレゼンスの確認が必要な場合
追加のブート サイクルが必要な場合があります
0
操作は実行されません
M
1-4
操作は実行されません
M
5
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear はFALSEです
X
6から11
操作は実行されません
M
12 月 13 日
操作は実行されません
O
14
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear はFALSEです
X
15日から16日
操作は実行されません
M
17
SetNoPPIClear_False
X
O1
18
SetNoPPIClear_True
X
O1
Always
19 から 20
操作は実行されません
O2
21から22
TPM2_ClearControl(NO) +
TPM2_Clear
X
M
NoPPIClear はFALSEです
X
23から 127
予約済み
>=128
ベンダー固有
X
X
O
X
重要
たとえば SetNoPPIClear_False:BIOS が "O1" または "O2" とマークされた項目を実装する場合は、それらをセットとして実装する必要があります。 後 に続 く No Operation SetNoPPIClear_True操作 12 を実装しない場合、BIOSは操作 19 と 20 を実装ししてはなりません。
表3は以下のように改訂されています:
操作
Value
操作
名前
操作を実行するために BIOS および他の BIOS アクションによって送信される TPM コマンド
0
操作は実行されません
操作は実行されません
1-4, 6-13, 15-16, 19-20
操作は実行されません
何も実行しません。 ただし、操作番号は記憶する必要があります。OS からクエリを実行した場合は、成功を返す必要があります。
5, 14, 21, 22
Clear
TPM2_ClearControl(NO) +
TPM2_Clear
<PLATFORM RESET> * [*TPM の変更を保持するために必要な場合は、TPM2_CLEAR。 Microsoft は、ほとんどのシステムでこれが不要と予測しています。
17
SetNoPPIClear_False
(クリアするには物理的なプレゼンスが必要です。)
この操作では、TPM の状態は変更されません。
BIOS TPM 管理フラグ NoPPIClear を FALSE にクリアします。
18
SetNoPPIClear_True
(クリアのために物理的なプレゼンスの確認は必要ない。)
この操作では、TPM の状態は変更されません。
BIOS TPM 管理フラグ NoPPIClear を TRUE にクリアします。
23から 127
予約済み
予約済み、実装しない、または使用しない
>=128
ベンダー固有
ベンダー固有の操作にマッピングされる TPM コマンド
操作を実行する必要があるが、実際のメカニズムがキーを押す必要はない場合は、物理的に存在するユーザーから確認を得るために、セクション 4 の精力を維持する必要があります。 同意を確認するためのキーまたは他のメカニズムは、プラットフォームの製造元によって異なります。
演算子
Value
操作
名前
確認
Text
5、14、21、そして22
Clear
このコンピューターの TPM をクリアするために構成の変更が要求されました (トラステッド プラットフォーム モジュール)
警告: をクリアすると、TPM に格納されている情報が消去されます。 作成されたキーと、これらのキーによって暗号化されたデータへのアクセスはすべて失われる可能性があります。
TPM をクリアするには<CAK>を押してください
この変更リクエストを拒否するか続行するには<RK> を押してください
18
SetNoPPIClear_True
今後ユーザーの確認を求めることなく、オペレーティング システムがコンピューターの TPM (トラステッド プラットフォーム モジュール) をクリアできる構成の変更が要求されました。
注意: このアクションでは TPM はクリアされませんが、この構成の変更を承認することで、TPM をクリアする今後のアクションでは、ユーザーの確認は必要とされません。
警告: をクリアすると、TPM に格納されている情報が消去されます。 作成されたキーと、これらのキーによって暗号化されたデータへのアクセスはすべて失われる可能性があります。
今後のオペレーティング システム要求を承認して TPM をクリアするには、<CAK> を押します
この変更リクエストを拒否するか続行するには<RK> を押してください
セクション 5 は有益です。
接続スタンバイ システムでは、NoPPIClear を TRUE にハードコーディングできます。操作 17 と 18 は実装されません。 つまり、物理的なプレゼンス操作ではユーザーの確認が必要ではないので、物理的なプレゼンス アクションの確認ダイアログを実装する必要はありません。
ファームウェアは、Windows Boot Manegerのような初期プログラム ローダー コードに制御を渡す際に、ストレージと承認階層を有効のままにする必要があります。
4.3.4.3 オプション ACPI 開始メソッド
注: 一部のプラットフォームでは、このオプションの ACPI メソッドを実装して、OS が TPM 2.0 コマンドの実行またはキャンセルをファームウェアに要求できる場合があります。 ACPI Start メソッドの使用は、静的 ACPI テーブルの StartMethod フィールドによって決まります (セクション 4.4 を参照)。静的 ACPI テーブルの StartMethod フィールドにこのメソッドの使用が示されている場合は、ACPI Start メソッドを実装する必要があります。ここで定義する ACPI 関数は、 コントロール メソッド オブジェクト_DSMに存在する必要があります。 [注: これは TPM2 ACPI テーブルの制御メソッドではありません。] ここで定義される_DSMメソッドは、次のように実装する必要があります:
UUID |
リビジョン |
Function |
説明 |
6bbf6cab-5463-4714-b7cd-f0203c0368d4 |
0 |
0 |
「[ACPI09]、セクション 9.14.1」で説明されています。 |
0 |
1 |
開始 |
関数の開始
入力引数:
Arg0 (Buffer): UUID = 6bbf6cab-5463-4714-b7cd-f0203c0368d4
Arg1 (Integer): Revision ID = 0
Arg2 (Integer): Function Index = 1
Arg3 (Package): Arguments = Empty Package
戻り値:
型: 整数
戻り値の説明:
0: 成功
1:一般エラー
機能動作:
この関数は、TPM 2.0 デバイス制御領域の状態レジスタを確認し、TPM 2.0 コマンドを実行または取り消す適切なアクションを実行する必要があります。
関数は非ブロッキングです。 呼び出しはすぐに返されます。 (ACPI メソッド内からコマンドの実行を試みないでください。AML 呼び出しは短くする必要があります)。)戻り値 0 が返されると、送信されたコマンドが受け入れられ、ファームウェアによって実行されるか、Cancel フィールドが既に設定されている場合は取り消されます。 可能な限り、システムは、この呼び出しから一般的なエラーではなく TPM 応答を返す必要があります。 たとえば、現在はコマンドを処理できない場合、応答バッファーが書き込TPM2_RC_RETRY フィールドが書き込まれSTARTフィールドは CLEARed にできます。 Cancel フィールドが設定されたためコマンドが取り消された場合、このメソッドは応答バッファーに TPM2_RC_Cancelled リターン コードを書き込み、Start フィールドをクリアして値 0 を返します。 または、Cancel フィールドが設定されている場合、メソッドは値 0 を返し、TPM 2.0 デバイスは後でコマンドをキャンセルする要件に従ってコマンドを完了または取り消す場合があります。
戻り値 1 が返された場合、ファームウェアは要求に対して読み取りまたは処理を実行できません。 戻り値以外の要求は NO-OP と同じです。 たとえば、(a) 以前のコマンドが完了する前に、OS ドライバーが追加のコマンドの実行を要求する、(b) 制御領域が物理メモリ内に存在しない 、おそらくメモリが壊れている、または (c) コマンドまたは応答の物理アドレスが存在しないなどです。 戻り値が 1 の場合、Windows TPM 2.0 ドライバーは、次のシステムの完全な起動まで TPM 2.0 デバイスの使用を停止する可能性があります (これは休止/再開サイクルを除く)。
注意: コマンドの実行が開始されると、OS が現在実行中のコマンドの取り消しを選択した場合、このメソッドは 2 回目は呼び出されません。 (ただし、cancel フィールドが設定されている間は、コマンドに対してコントロール メソッドを最初に呼び出す可能性があります)。
}4.4 TPM2 静的 ACPI テーブル
"RSDT" ACPI テーブルに記載されている "TPM2" という名前の ACPI テーブルは、プラットフォームの TPM 2.0 ハードウェア インターフェイスについて説明します。 このWindows TPM 2.0 ドライバーは、このテーブルを使用して、TPM 2.0 デバイスと通信する方法を決定します。 このインターフェイスをサポートするために必要な ACPI テーブルのパラメーターを次の表に示します。
表 3: TPM2 ACPI テーブル レイアウト
フィールド |
バイト長 |
バイト オフセット |
説明 |
||||||||||||||
ヘッダー |
|||||||||||||||||
署名 |
4 |
00h |
'TPM2'. TPM 2.0 デバイスハードウェア インターフェイス テーブルの署名 |
||||||||||||||
長さ |
4 |
04h |
ヘッダーを含む、オフセット 0 から始まるテーブルの長さ (バイト単位)。 このフィールドは、テーブル全体のサイズを記録するために使用されます。 |
||||||||||||||
リビジョン |
1 |
08h |
このテーブルによって参照されるデータと構造を含む、このテーブルのリビジョン。 この によって参照される構造体が変更された場合 (コントロール領域など)、このリビジョンは変更する必要があります。 値 03h。 |
||||||||||||||
Checksum |
1 |
09h |
チェックサム フィールドを含むテーブル全体で、有効と見なされる 0 に追加する必要があります。 |
||||||||||||||
OEM ID |
6 |
0Ah |
ACPI 仕様ごとの OEM ID。 OEM を識別する OEM 提供の文字列 (チップセット ベンダーの場合があります)。 |
||||||||||||||
OEM テーブル ID |
8 |
10h |
OEM テーブル ID は製造元モデル ID です ("OEM ID" で識別される OEM によって割り当てられます。チップセット ベンダーの場合があります)。 |
||||||||||||||
OEM 改訂番号 |
4 |
18h |
指定された OEM テーブル ID の OEM リビジョン。 ACPI ごとに、"[an] OEM 提供のリビジョン番号。 より大きな数値は、新しいリビジョンであると見なされます。" |
||||||||||||||
作成者 ID |
4 |
1Ch |
テーブルを作成したユーティリティのベンダー ID。 定義ブロックを含むテーブルの場合、これは ASL コンパイラの ID です。 |
||||||||||||||
作成者改訂番号 |
4 |
20h |
テーブルを作成したユーティリティの改訂番号。 定義ブロックを含むテーブルの場合、これは ASL コンパイラの ID です。 |
||||||||||||||
Flags |
4 |
24h |
予約済み 常に 0 である必要があります。 |
||||||||||||||
制御領域のアドレス |
8 |
28h |
コントロール領域の物理アドレス。 TPM 2.0 デバイス メモリ内、または起動時にシステムによって予約されたメモリ内のいずれかにある場合があります。 TPM 2.0 ドライバーは、休止サイクルや再開サイクルなど、ブート サイクル全体でこのアドレスに関する知識を保持します。 システムが制御領域を使用しない場合、この値はすべてゼロである必要があります。 |
||||||||||||||
Start メソッド |
4 |
30h |
開始メソッド セレクターは、Windows TPM 2.0 ドライバーが TPM 2.0 コマンドをデバイスに通信し、コマンドが処理可能だと TPM 2.0 デバイスに通知するために使用するメカニズムを決定します。 このフィールドには、次のいずれかの値を含めることができます:
|
||||||||||||||
プラットフォーム固有のパラメーター |
変数 |
34h |
プラットフォーム固有のパラメーターの内容は、このシステムの TPM 2.0 デバイス インターフェイスで使用される開始メカニズムによって決まります。 このフィールドには、コマンド処理を開始するために使用できる値が含まれます。 この情報はベンダー固有の場合があります。 Start メソッドの値が 2 または 6 の場合、フィールドは使用されません。Byte Length は 0 です。 |
4.4.1 コントロール領域の内容
制御領域構造には、状態フィールドだけでなく、他の制御ビット/フィールドと 1 つ以上のアドレスが含まれます。 制御領域には、コマンド バッファーの物理アドレスと応答バッファーの物理アドレスが含まれます。
一部の TPM 2.0 インターフェイス実装で制御領域が使用されているとは言え、たとえば Start Method 値 6 では制御領域が使用されません。このセクションの情報はプラットフォームには適用されません。
コントロール領域は、ACPI AddressRangeReserved メモリ内にある必要があります。
コントロール領域の構造を次の表に示します。特に指定しない限り、コントロール領域へのすべてのアクセスは、リトル エンディアン形式で行われます。
表 4: コントロール領域のレイアウト
|
フィールド |
バイト長 |
Offset |
説明 |
状態フィールド |
TPM 2.0 の状態フィールド |
||
予約済み |
4 |
00h |
予約済み。 (ゼロを指定してください。) |
エラー |
4 |
04h |
エラー状態を示すために TPM 2.0 によって設定される |
キャンセル |
4 |
08h |
ドライバーがコマンド処理を中止する SET |
開始 |
4 |
0Ch |
コマンドが処理可能な状態を示す場合は、DRIVER によって設定されます。 |
割り込み制御 |
8 |
10h |
予約済み。 (ゼロを指定してください。) |
コマンド サイズ |
4 |
18h |
コマンド バッファーのサイズ |
コマンド |
8 |
1Ch |
このフィールドには、コマンド バッファーの物理アドレスが含まれます。 注意実際のコマンド バッファー (コマンド バッファーの物理アドレスではない) は、TCG で義務付けされているビッグ エンディアン形式です。 |
応答サイズ |
4 |
24h |
応答バッファーのサイズ |
[応答] |
8 |
28h |
このフィールドには、応答 バッファーの物理アドレスが含まれます。 注意実際の応答バッファー (コマンド バッファーの物理アドレスではない) は、TCG で義務付けされているビッグ エンディアン形式です。 |
TPM 2.0 ドライバーは、オペレーティング システムの初期化中に次の情報を 1 回読み取ります:
コントロール領域の物理アドレス
コマンド バッファーのサイズ
コマンド バッファーの物理的な場所
応答バッファーのサイズ
応答バッファーの物理的な場所
制御領域を使用するシステム (つまり、Start メソッドの値が 6 と等しくない) と休止と再開をサポートする場合、上記の 5 つの値は休止サイクルと再開サイクル間で一定のままである必要があります。
4.4.1.1 エラー
TPM 2.0 デバイスでこの状態が設定される場合があります。 Start が SET の場合にのみ、この状態が書き込まれる場合があります。 TPM 2.0 デバイスは、この状態をセットした直後に Start 値を CLEARs します。 TPM 2.0 ドライバー Windows開始フィールドが CLEAR ではない限り、エラー フィールドは読み込めません。
[エラー] フィールドの SET 値は、TPM 2.0 デバイスまたはハードウェア インターフェイスの一般的なエラーとして扱います。 SET 値を指定すると、現在のコマンドが取り消されます。 TPM 2.0 デバイスが一貫性のある状態を保つには、コマンドをロールバックする必要があります。
ACPI Start メソッドを使用するデバイスの場合、このフィールドは、応答コードを指定できないエラーにのみ使用する必要があります。 たとえば、応答バッファーが物理メモリ内にはない場合です。 このWindows TPM 2.0 ドライバーは、このフィールドが SET のときに TPM 2.0 デバイスの使用を停止する可能性があります。
ExitBootServices の後のこのフィールドの初期値は、デバイスが動作するかどうかを反映する必要があります。
4.4.1.2キャンセル
Windows TPM 2.0 ドライバーは 、このフィールドを設定して、現在のコマンドの TPM 2.0 デバイス処理を終了するよう要求することがあります。 Windows TPM 2.0 ドライバー は開始要求のキャンセルの処理をするため開始メソッドを呼び出しません。
Windows TPM 2.0 ドライバーによって Cancel が設定され、TPM 2.0 デバイスがコマンドを処理している場合、TPM 2.0 デバイスは最も早い時点で現在のコマンドの処理を停止します。 ほとんどのコマンドでは、TPM 2.0 デバイスがコマンドを完了し、通常の応答を提供する必要があります。 実行時間の長いコマンド (RSA キーの生成など) の場合、TPM 2.0 デバイスは、次のコマンドで終了TPM_RC_CANCELLED。 TPM 2.0 デバイスは、90 分以内にコマンドを完了するか取り消す必要があります。 (一般に、ほとんどの TPM 2.0 コマンドは 500 ミリ秒未満で完了する必要があります。ただし、RSA キー生成コマンドには時間がかかる場合があります。コマンドのキャンセルは 200 ミリ秒以内に行う必要があります)
Windows TPM 2.0 ドライバーでは、スタート フィールドが CLEAR の場合、この値がクリアされる場合があります。 ExitBootServices の後のこのフィールドの初期値は CLEAR である必要があります。
4.4.1.3Start
Windows TPM 2.0 ドライバー 新しいコマンドがコマンド バッファーに配置されたかどうかを示すために、この状態を設定できます。 Windows TPM 2.0 ドライバー は開始要求のキャンセルの処理をするため開始メソッドを呼び出しません。 TPM 2.0 デバイスは、コマンドの処理が完了すると、この状態をクリアします。
START呼び出しに失敗すると、 Windows TPM 2.0 ドライバーでこの状態がクリアされる場合があります。
ExitBootServices の後のこのフィールドの初期値は CLEAR である必要があります。
4.4.1.4 コマンド
これは、Windows TPM 2.0 ドライバーが 実行するコマンドを書き込む物理アドレスです。 Windows TPM 2.0 ドライバー は、"コマンド サイズ" より大きいコマンドは書き込めません。
Windows TPM 2.0 ドライバーは 開始フィールドが CLEAR ではない限り、このメモリ領域に書き込めません。 アドレスはコントロール領域でリトル エンディアン形式で指定されますが、実際のコマンド バッファーは TCG で要求されるビッグ エンディアン形式です。
4.4.1.5 応答
これは、Windows TPM 2.0 ドライバーが応答を読み取る物理アドレスです。 Windows TPM 2.0 ドライバーは 、"応答サイズ" より大きい応答は読み取れません。
Windows TPM 2.0 ドライバー 開始フィールドが SET から CLEAR に変更され、エラーが CLEAR に変更された後にのみ応答が読み取りされます。 注意アドレスはコントロール領域でリトル エンディアン形式で指定されますが、実際のコマンド バッファーは TCG で要求されるビッグ エンディアン形式です。
4.5 コントロール領域インターフェイスの定義
TPM 2.0 インターフェイスとして制御領域を使用するハードウェア プラットフォームの場合、このセクションとセクション 4.4 の情報では、TPM 2.0 ドライバーとハードウェアとの対話操作について説明します。 コントロール領域を使用するシステムの例として、TPM2 テーブルの Start メソッドの値が 2 のシステムがあります。
4.5.1 状態の組み合わせ
表 5 に、Windows TPM 2.0 ドライバーによる予想される動作を示します。 一部の組み合わせだけが許可される点に注意してください。 許可されている組み合わせと変更だけが文書化されます。 他のすべての組み合わせは無効です。 Windows TPM 2.0 ドライバーによる操作なしでフィールドが変更されるということは、TPM 2.0 デバイスまたは ACPI Start メソッドによってフィールドを変更したという意味です。
'0' でマークされた状態は、このフィールドが CLEAR を示します。 '1' でマークされた状態は、このフィールドが SET を示します。 '?' でマークされた状態は、このフィールドの値が CLEAR または SET のいずれかである可能性を示します。 状態フィールドは、'ERR' - Error、'CCL' - Cancel、および 'STR' - Start という省略形で示されます。 フィールドは、Windows TPM 2.0 ドライバーまたは TPM 2.0 デバイス インターフェイス (アクション列で詳しく説明) によって記述できます。
|--- |
現在の状態 |
---| |
|--- |
フィールドの書き込み |
---| |
|--- |
次の状態 |
---| |
TPM 2.0 デバイス インターフェイスによって実行されるアクション |
|
# |
ERR |
CCL |
STR |
ERR |
CCL |
STR |
ERR |
CCL |
STR |
|
1 |
0 |
1 |
0 |
- |
0 |
- |
0 |
0 |
0 |
次Windows TPM 2.0 ドライバー CLEARs の Cancel 値を使用して、次のコマンドのコントロール領域を準備します。 Windows TPM 2.0 ドライバーは 、START が CLEAR の場合にのみ[キャンセル] の値をクリアできます。 (TPM 2.0 デバイスは[キャンセル] フィールドに書き込まないでください。) |
2 |
0 |
0 |
0 |
- |
- |
1 |
0 |
0 |
1 |
このWindows TPM 2.0 ドライバーは、コマンドが [コマンド] 領域に存在すると示す Start 値を設定します。 Windows TPM 2.0 ドライバー は、ACPI Start メソッドを呼び出してコマンドの実行を開始できます。 ACPI Start メソッドが完了したら、TPM 2.0 デバイスはコマンドを完了し、90 分以内に [開始] フィールドをクリアする必要があります。 制限時間を超えた場合、TPM 2.0 ドライバー Windows TPM 2.0 デバイスがハングしている可能性があります。 |
3 |
0 |
? |
1 |
- |
- |
0 |
0 |
? |
0 |
TPM 2.0 デバイスは、コマンドの処理が完了するか、コマンドを取り消す際に[スタート] フィールドを CLEARs します。 コマンドが取り消された場合、リターン コードが含TPM_RC_CANCELLEDが応答バッファーに配置され、Start が CLEARed になります。 Windows TPM 2.0 ドライバー 開始フィールドが CLEAR の間に応答バッファーを読み取る場合があります。 Windows TPM 2.0 ドライバーは 開始フィールドが SET の間に応答バッファーを読み取れません。 |
4 |
0 |
0 |
1 |
- |
1 |
- |
0 |
1 |
1 |
このWindows TPM 2.0 ドライバー SET Cancel を使用して、現在のコマンドをキャンセルする TPM 2.0 デバイスを示します。 一般に、実行時間の長いコマンドは、次の利便性のある時点で取り消す必要があります。 実行時間の短いコマンドが完了する場合があります。 具体的には、TPM 2.0 デバイスは、[キャンセル] フィールドが設定された後、90 分以内に [開始] フィールドをクリアする必要があります。 (適切なパフォーマンス 目標は 90 秒ではなく 200 ミリ秒です)。注: OS 内の 1 つのスレッドが ACPI Start メソッドを呼び出す前に Cancel フィールドを設定できるため、ACPI Start メソッドが呼び出されたときに Cancel フィールドが設定される可能性があります。 |
5 |
0 |
? |
1 |
1 |
- |
- |
1 |
? |
1 |
TPM 2.0 デバイスは、デバイスのエラー状態を示します。 TPM 2.0 デバイスの状態は、コマンドの実行が開始されたことがない場合と同じになります。 Windows TPM 2.0 ドライバー はTPM 2.0 ドライバーの、この値を TPM 2.0 デバイスの一般的な障害として扱い、コマンドの処理を取り消します。 |
6 |
1 |
? |
1 |
- |
- |
0 |
1 |
? |
0 |
TPM 2.0 デバイス CLEARs の Start フィールドは、SETting の直後の [エラー] フィールドです。 Windows TPM 2.0 ドライバーは 、Start フィールドが CLEAR の場合、または必要な時間内にコマンドの実行またはキャンセルが発生しない場合にのみ、[エラー] フィールドを検査します。 このWindows TPM 2.0 ドライバーは、このフィールドが SET のときに TPM 2.0 デバイスの使用を停止する可能性があります。 |
4.5.2 ACPI Start メソッドを使用する場合の状態図
この状態図は、情報提供のみを目的とします。 動作の規範的な説明は、前のセクションのテキストです。 状態遷移が見つからないかあいまいな場合は、上記のテキストを参照してください。
図 1: ACPI Start メソッドを使用する場合の TPM 2.0 デバイスの状態
Note
(a) 複数の同時実行スレッドがコントロール領域と同時に対話できる点に注意してください。 たとえば、1 つのスレッドが Start フィールドを設定し、Start メソッドを発行することでコマンドを開始できます。 別のスレッドでは、Cancel フィールドを並列で設定できます。 そのため、Start フィールドを設定した後、Start メソッドを発行する前に Cancel フィールドを設定する可能性があります。 (b)Windows TPM 2.0 ドライバーが、示されているエラー状態とは異なる方法で対応する場合があります。 たとえば、タイムアウトが発生するとエラー状態に遷移する場合があります。
4.5.3 ACPI Start メソッドを使用しない状態図
この状態図は、情報提供のみを目的とします。 動作の規範的な説明は、前のセクションのテキストです。 状態遷移が見つからないかあいまいな場合は、上記のテキストを参照してください。
図 1: ACPI Start メソッドなしの TPM 2.0 デバイスの状態
4.6 メモリ マップ I/O インターフェイス
TPM 2.0 インターフェイスとして制御領域を使用するハードウェア プラットフォームの場合、このセクションとセクション 4.4 の情報では、TPM 2.0 ドライバーとハードウェアとの対話操作について説明します。 コントロール領域を使用するシステムの例として、TPM2 テーブルの Start メソッドの値が 6 のシステムがあります。
4.6.1インターフェイス仕様の要件
システムは、次のセクションの [TCG12] の TPM 1.2 ハードウェア インターフェイス要件に準拠している必要があります:
セクション 9.1: TPM の局所性レベル
セクション 9.2: 局所性の使用
セクション 9.3: レジスタあたりの局所性の使用状況
セクション 10: TPM レジスタ領域
セクション 11: システムの相互作用とフロー
例外: セクション 11.2.4 エラー モードのすべて
例外セクション 11.2.5 : コマンドの実行時間、標準項目 2
セクション 11.2.6 のすべてを除く: タイムアウト
セクション 11.2.8: 自己テストと初期のプラットフォーム初期化のすべてを除きます。
すべてのセクション 11.2.9: 入力バッファーサイズを除く
セクション 11.2.10: Errors、non-normative items 2c、3を除く。
セクション 13: TPM ハードウェアプロトコル
[TCG12] の将来のドラフト仕様については、Microsoft にお問い合わせください。
4.6.2 のコマンド取り消しのサポート
Windows では、次に説明する動作を示すことにより、TPM 2.0 デバイスで、メモリマップ I/O インターフェイスを使用して TPM2.0 コマンドの取り消しを許可する必要があります。
STS レジスタの以前に未使用のビット24は、書き込み専用として定義され、commandCancel と呼ばれています。
コマンド実行フェーズ中に ' 1 ' を commandCancel に書き込むと、現在実行中のコマンドがキャンセルされ、応答が返される必要があります。 この応答は、コマンドがキャンセルされた (TPM 2.0 状態の変更はありませんが、キャンセル応答コード TPM_RC_CANCELLED が返されます) か、完了したかを示します (コマンドの結果を示す通常の TPM 2.0 応答が返されます)。 TPM がコマンドの実行状態ではないときに commandCancel レジスタに書き込みを無視する必要があります。
4.6.3 追加の要件
すべての TPM コマンドは、最大90秒以内に完了する必要があります。
TPM 2.0 ドライバーがコマンドのキャンセルを要求する場合は、90秒以内に完了またはキャンセルする必要があります。
次のタイムアウト値を実装する必要があります: TIMEOUT_A = 1 秒、TIMEOUT_B = 2 秒、TIMEOUT_C = 1 秒、TIMEOUT_D = 1 秒。
最小入力バッファーサイズは 0x500 (またはそれ以上) である必要があります。
5.0参考資料
[ACPI09] |
Advanced Configuration and Power Interface の仕様 Version 4.0、6月16日2009。 |
[TCG08] |
Trusted Computing Group、「TCG プラットフォームリセット攻撃の緩和仕様」、「バージョン1.0、5月15日2008。 |
[TCG11] |
Trusted Computing Group、"TCG 物理プレゼンスインターフェイス仕様" バージョン1.20、2月10日2011。 |
[TCG12] |
Trusted Computing Group、「PC クライアントの作業グループ PC クライアント固有の TPM インターフェイス仕様 (TIS) バージョン1.21、リビジョン1.00。 |