SoC プラットフォームのすべての Windows エディションに適用される UEFI 要件

  • [アーティクル]

このトピックでは、デスクトップ エディション (Home、Pro、Enterprise、Education) の Windows 10 と Windows 10 Mobile に適用される UEFI の要件について説明します。Windows 10 Mobile にのみ適用されるその他の要件については、「Windows 10 Mobile の UEFI 要件」をご覧ください。

要件の要約

次の表は、UEFI 仕様で定義されている、UEFI 準拠のためのすべての現行の要件を示します (UEFI 2.3.1 仕様のセクション 2.6)。次の表では、"明示的な Windows 要件" という用語で、Windows コンポーネントから直接呼び出されるあらゆるプロトコルまたはサービスを識別しています。これらのサービスは、Windows によって明示的に使われますが、一覧にあるその他のサービスやプロトコルは、コア ファームウェア実装、EFI デバイス ドライバー、または開発ツール チェーンと展開ツール チェーンに暗黙で、または明示的に必要となります。

Microsoft では、実装したお客様からの、この一連の要件についてのフィードバックとコメントをお待ちしています。 OS とファームウェアのいずれでも必要でないと判断されたすべての UEFI 準拠要件については、このクラスのデバイスに対してこれらの準拠要件が緩和されるよう、UEFI.org とともに取り組むことになります。

特定の要件の詳細については、表の後の各セクションをご覧ください。

要件 UEFI 仕様のセクション 注意事項
EFI システム テーブル 4.3 明示的な Windows 要件
EFI ブート サービス 6.0
  イベント、タイマー、およびタスク サービス 6.1
  メモリ サービス 6.2 明示的な Windows 要件
  プロトコル ハンドラー サービス 6.3 明示的な Windows 要件
  イメージ サービス 6.4 明示的な Windows 要件
  その他のサービス 6.5 明示的な Windows 要件
EFI ランタイム サービス 7.0
  タイム サービス 7.3 明示的な Windows 要件
  変数サービス 7.2 明示的な Windows 要件
  その他のサービス 7.5 明示的な Windows 要件
必要な UEFI プロトコル
  EFI 読み込み済みイメージ プロトコル 8.1
  EFI 読み込み済みイメージ デバイス パス プロトコル 8.2
  EFI デバイス パス プロトコル 9.2 明示的な Windows 要件
  EFI デバイス パス ユーティリティ プロトコル 9.5
  EFI 解凍プロトコル 18.5
  EBC インタープリター プロトコル 20.11
条件的に必要な UEFI プロトコル
  EFI シンプル テキスト入力プロトコル 11.3 明示的な Windows 要件
  EFI シンプル テキスト入力 EX プロトコル 11.2
  EFI シンプル テキスト出力プロトコル 11.4
  EFI グラフィックス出力プロトコル 11.9 明示的な Windows 要件
  EFI EDID 検出済みプロトコル 11.9.1
  EFI EDID アクティブ プロトコル 11.9.1
  EFI ブロック IO プロトコル 12.8 明示的な Windows 要件
  EFI ディスク IO プロトコル 12.7
  EFI シンプル ファイル システム プロトコル 12.4
  EFI Unicode 照合プロトコル 12.10
  EFI シンプル ネットワーク プロトコル 21.1
  EFI PXE ベース コード プロトコル 21.3
  EFI ブート整合性サービス プロトコル 21.5
  EFI シリアル IO プロトコル 11.8
  UEFI ARM バインディング 2.3.5 明示的な Windows 要件
セキュリティ要件
  セキュア ブート 27.0 明示的な Windows 要件
  ブート マネージャーの要件 3.1、3.3 明示的な Windows 要件

 

EFI システム テーブルの要件

EFI システム テーブルは、実装されるリビジョン レベルで標準の定義に従っている必要があります。EFI システム テーブルが指す構成テーブルは、次の表に示す 2 つの GUID と、それらに関連付けられているポインターを含む必要があります。

GUID 説明
EFI_ACPI_Table GUID

この GUID は、プラットフォームの ACPI ルート システム記述ポインター (RSDP) を指す必要があります。
SMBIOS_Table GUID

この GUID は、SMBIOS エントリ ポイント構造体を指す必要があります。

Windows には、2.4 以降のリビジョン レベルの SMBIOS 仕様が必要です。 セクション 3.2、「Required Structures and Data」(必要な構造体とデータ)、およびセクション 4、「Conformance Guidelines」(準拠ガイドライン) が必要です。Windows の SMBIOS 互換性テストが入手可能です。

 

EFI ブート サービスの要件

次の表は、Windows の EFI ブート サービスの要件の一覧です。

EFI ブート サービス 要件
メモリ サービス Windows には、すべてのメモリ サービスが必要です。
プロトコル ハンドラー サービス

Windows には、次のプロトコル ハンドラー サービスが必要です。

  • OpenProtocol()

  • CloseProtocol()

  • LocateDevicePath()

  • LocateHandle()
イメージ サービス

Windows には、次のイメージ サービスが必要です。

  • ExitBootServices()
その他のブート サービス

Windows には、次のその他のブート サービスが必要です。

  • Stall()

注  Stall() 実装では、エラー訂正または取り消しが確実に行われるように、決定的 (反復可能) なエラーが生成される必要があります。
 

 

EFI ランタイム サービスの要件

次の表は、Windows の EFI ランタイム サービスの要件の一覧です。

EFI ランタイム サービス 要件
タイム サービス

Windows には、次のタイム サービスが必要です。

  • GetTime()

  • SetTime()

    注  タイム サービスは、プラットフォームの time-of-day ハードウェアにアクセスするために、起動中 (ExitBootServices() の前) にのみ呼び出されます。

     
変数サービス

すべての UEFI 変数サービスは、複数のブート デバイスと、システムのターゲット クラスのセキュリティ変数を管理するために必要です。
その他のランタイム サービス

Windows には、次のその他のランタイム サービスが必要です。

  • ResetSystem()

    注  ResetSystem() 実装は、リセットとシャット ダウンのオプションを両方ともサポートする必要があります。

     

 

プロトコルの要件

次の表では、起動中に特定の機能を実現するために Windows に必要な UEFI プロトコルについて説明します。

プロトコル 要件
グラフィックス出力プロトコル

Windows には、グラフィックス出力プロトコル (GOP) が必要です。 具体的なフレーム バッファーの要件は次のとおりです。

  • 統合ディスプレイでは、HorizontalResolution と VerticalResoluton が、パネルのネイティブの解像度である必要があります。

  • 外付けディスプレイでは、HorizontalResolution と VerticalResoluton が、ディスプレイのネイティブの解像度である必要があります。または、これがサポートされていない場合は、ビデオ アダプターおよび接続されているモニターの両方でサポートされる最高の値である必要があります。

  • PixelsPerScanLine は、HorizontalResolution と同じである必要があります。

  • PixelFormat は、PixelBlueGreenRedReserved8BitPerColor である必要があります。物理的なフレーム バッファーが必要です。PixelBltOnly はサポートされていません。

実行が UEFI アプリケーションに引き継がれる際には、どのような目的であっても、ファームウェア ブート マネージャーとファームウェアがフレーム バッファーを使うことはできません。フレーム バッファーのスキャンは、ブート サービスが終了した後も続行される必要があります。
別の表示出力

UEFI ファームウェアは、ハードウェアでサポートされている任意のディスプレイ コネクタを使用して起動をサポートする必要があります。内部パネルが接続されており、表示可能な場合は、内部パネルを使用してください。物理的に接続されているディスプレイへのすべての出力は、ブート画面を表示する必要があります。接続されているディスプレイでは、UEFI ファームウェアが、次の操作を実行する必要があります。

  • ネイティブの解像度を特定できる場合は、ディスプレイのネイティブ モードで出力を初期化します。

  • ネイティブ モードにすることができない場合は、最高の互換モードに初期化する必要があります。

  • 表示機能を特定できない場合は、接続されているディスプレイを、できるだけ多くのモニターとの互換性が確認されているモード (通常は、60 Hz で 640 x 480 または 1024 x 768) で初期化する必要があります。
起動時の入力

EFI シンプル テキスト入力プロトコルは、キーボードが組み込まれているか、接続されているシステムで起動時の選択やその他のメニューの選択を行うために必要です。キーボードのないシステムでは、ブート環境の 3 つのボタンをお勧めします。

  • [スタート] ボタン

  • [音量を上げる] ボタン

  • [音量を下げる] ボタン

ボタンの押下は、それぞれに次のキーボード キーをマッピングすることによって、EFI シンプル テキスト入力プロトコルを通じて報告される必要があります。

  • Windows キー

  • 上方向キー

  • 下方向キー
ローカル ストレージの起動

ストレージ ソリューションに EFI システム パーティションと Windows OS パーティションが含まれている場合は、Windows が、ブロック I/O プロトコルとデバイス パス プロトコルをサポートする必要があります。ウェアレベリングまたはその他のフラッシュ管理が必要なフラッシュ ストレージから起動する場合は、これをファームウェア (UEFI アプリケーションではなく) に実装する必要があります。

 

セキュリティ要件

Windows には、セキュア ブート、メジャー ブート、暗号化、およびデータ保護の領域のセキュリティ要件があります。これらの要件について、次の表で詳しく説明します。さらに、SoC ハードウェアが原因で既存の標準 (TPM、RTC など) に準拠できない領域については、追加の要件が作成されています。これらについては、表の最後で説明しています。

領域 要件
全般

  • 要件 1: 必須。プラットフォームは、このセクションで指定されているすべての要件に準拠します。

  • 要件 2: 必須。プラットフォームは UEFI クラス 3 です。互換性サポート モジュールはインストールされておらず、インストールすることもできません。 BIOS のエミュレーションとレガシ PC/AT 起動が無効になっている必要があります。
UEFI セキュア ブート

  • 要件 3: 必須。出荷時に、UEFI v2.3.1 のセクション 27 で定義されているセキュア ブートが有効になっており、あらかじめプロビジョニングされたコンピューターを安全に起動するために必要な署名データベース (EFI_IMAGE_SECURITY_DATABASE) が搭載されている必要があります。署名データベースの初期の内容は、必要なサード パーティ製 UEFI ドライバー、回復の必要性、コンピューターにインストールされている OS ブート ローダーに基づいて OEM が決定します。ただし、Microsoft が提供する EFI_CERT_X509 署名が含まれるものとします。その他の署名は存在しません。

  • 要件 4: 必須。UEFI "禁止" 署名データベース (EFI_IMAGE_SECURITY_DATABASE1) が存在する必要があります。

  • 要件 5: 必須。Microsoft が提供する UEFI KEK が UEFI KEK データベースに含まれます。その他の KEK は存在しません。マイクロソフトは、EFI_CERT_X509 署名の形式の KEK を提供します。

  • 要件 6: 必須。A PKpub キーが存在し、ファームウェアのフラッシュに格納されています。

    注  PKpub でプロビジョニングされたすべてのデバイスでは、PKpriv (PKpub に対応する秘密キー) がセキュア ブート ポリシーを管理するため、その保護と使用を厳密に保護する必要があります。

     

  • 要件 7: 必須。初期の署名データベースはフラッシュ ファームウェアに格納され、OEM が署名したファームウェア更新プログラム、または UEFI 認証済み変数書き込みでのみ更新することができます。

  • 要件 8: 必須。署名の確認できなかったブート パス内のイメージは実行できません。また、確認できなかった理由は EFI_IMAGE_EXECUTION_TABLE に追加されます。さらに、このような状況で推奨されるアプローチは、UEFI ブート マネージャーが、OEM 固有の方針に従って回復を開始することです。

  • 要件 9: 必須。物理的に存在するユーザー オーバーライドを、署名を確認できなかった UEFI イメージに対しては許可することはできません。

  • 要件 10: 省略可能。OEM は、PKpriv へのアクセス、またはファームウェアのセットアップによる物理プレゼンスを使用して、物理的に存在するユーザーがセキュア ブートを無効にする機能を実装できます。ファームウェアのセットアップへのアクセスは、プラットフォーム固有の方法 (管理者のパスワード、スマート カード、静的な構成など) で保護できます。

  • 要件 11: 要件 10 が実装されている場合は必須。セキュア ブートが無効になっている場合は、既存のすべての UEFI 変数にアクセスできません。

  • 要件 12: 省略可能。OEM は、物理的に存在するユーザーが、ファームウェアのセットアップで 2 つのセキュア ブート モード、"カスタム" と "標準" のいずれかを選択できる機能を実装できます。カスタム モードでは、次の要件で指定されるように、柔軟性がより高くなります。

  • 要件 13: 要件 12 が実装されている場合は必須。所有者固有の PK を設定して、無効になっているセキュア ブートをカスタム モードで再び有効にすることができます。管理は、UEFI 仕様 v2.3.1 のセクション 27.5「Firmware/OS Key Exchange」(ファームウェア/OS キー交換) での定義に従って実行します。カスタム モードでは、デバイスの所有者が署名データベースに署名の選択を設定できます。

  • 要件 14: 要件 12 が実装されている場合は必須。ファームウェアのセットアップは、セキュア ブートが有効かどうかと、標準モードとカスタム モードのどちらで運用しているかを示します。ファームウェアのセットアップは、カスタム モードから標準モードに戻すオプションを提供します。

  • 要件 15: 必須。ファームウェアの設定が工場出荷時の既定値にリセットされた場合は、カスタム設定で保護されている変数がすべて消去され、元の PKpub が、製造元がプロビジョニングした最初の署名データベースとともに再度確立されます。

  • 要件 16: 必須。ドライバーの署名では、Authenticode オプション (WIN_CERT_TYPE_PKCS_SIGNED_DATA) を使用します。

  • 要件 17: 必須。EFI_IMAGE_EXECUTION_INFO_TABLE のサポート (つまり、起動中に開始された、または開始されていないイメージに関する情報の作成と保存)。

  • 要件 18: 必須。EFI_IMAGE_SECURITY_DATABASE (承認済みと禁止の両方の署名データベース) 用の GetVariable() のサポート。

  • 要件 19: 必須。Microsoft KEK を使った承認による、EFI_IMAGE_SECURITY_DATABASE (承認済みと禁止の両方の署名データベース) 用の SetVariable() のサポート。

  • 要件 20: 必須。EFI_HASH_SERVICE_BINDING_PROTOCOL: サービスのサポート: CreateChild()、DestroyChild()。

  • 要件 21: 必須。EFI_HASH_PROTOCOL。サービスのサポート: Hash()。SHA_1 および SHA-256 のハッシュ アルゴリズムのサポート。10 MB 以上の長いメッセージを渡すことをサポートする必要があります。
UEFI メジャー ブート

次の各要件は、TCG TPM の実装の必要性を意味するものではありませんが、影響を受ける領域には、同等の機能が必要であることを意味しています。

プラットフォームのサポートは、暗号化セキュリティで保護された実行環境で実行されている TPM のファームウェア実装によって提供することができます。このサポートは、暗号化アクセラレーション エンジンの上に重ねられ、分離ストレージを活用します。Microsoft は、このような TPM 実装のリファレンス ソフトウェアをベンダー用に提供できる可能性があります。これについては、さらに検討が必要です。

  • 要件 22: 必須。プラットフォームは、UEFI 信頼される実行環境 EFI プロトコルで指定された EFI プロトコルに準拠します。

  • 要件 23: 必須。プラットフォームは、次の追加項目を含め、TCG EFI プラットフォーム仕様に準拠します。

    • TrEE EFI プロトコルで定義されているインターフェイスをサポートするプラットフォーム上で、PKpub のダイジェストは、EV_EFI_VARIABLE_CONFIG イベントとして TPM PCR[03] に拡張されます。

    • 承認済み署名データベース (UEFI 仕様 v2.3.1 のセクション 27.8 を参照) リストのコンテンツのダイジェストを、EV_EFI_VARIABLE_CONFIG イベントとしてメジャー ブートで拡張する必要があります。拡張操作は、TPM PCR[03] に対して行われます。

    • UEFI クライアントは、EFI_IMAGE_SECURITY_DATABASE 変数を使用して証明書の一覧を読み取り、解析し、拡張された値と照合してダイジェストを検証できます。

    • TCG_PCR_EVENT ダイジェスト値は、SHA-1 ではなく、SHA-256 です。

  • 要件 24: 必須。プラットフォームは、TCG プラットフォーム リセット攻撃緩和仕様で定義されている MemoryOverwriteRequestControl を実装する必要があります。
暗号化

  • 要件 25: 必須。プラットフォームは、暗号化ハッシュ操作のオフロードのために EFI_HASH_PROTOCOL (UEFI v2.3.1 セクション 27.4) を提供します。SHA-256 をサポートする必要があります。

  • 要件 26: 必須。プラットフォームは、Microsoft が定義する EFI_RNG_PROTOCOL を、エントロピーの Pre-OS 読み取り用にサポートします。
データ保護

  • 要件 27: 必須。プラットフォームは、次の UEFI 変数属性セットの任意の組み合わせで EFI 変数をサポートする必要があります。

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
その他のセキュリティ要件

SoC プラットフォームの Windows には、次の追加要件が必要です。

  • Microsoft は、UEFI プラットフォームからエントロピーを収集するためのプロトコルを定義しています。UEFI 要件ではありませんが、このプロトコルは、SoC プラットフォームの Windows に必要です。このプロトコルについて詳しくは、「UEFI エントロピー収集プロトコル」をご覧ください。

  • UEFI 署名データベースの更新。UEFI 2.3.1 のセクション 27 では、認証済み変数を更新するための新しいメカニズムが採用されています。このメカニズムは、Windows に必要です。

  • 信頼される実行環境。Microsoft は、信頼される実行環境 (TrEE) を操作するための EFI プロトコルを開発しました。その機能は、Trusted Computing Group (TCG) トラステッド プラットフォーム モジュール (TPM) のサブセットと同様です。EFI プロトコルは、Trusted Computing Group による "TCG EFI プロトコル"、バージョン 1.2 リビジョン 1.00 (2006 年 6 月 9 日) を大幅に活用します。

    詳しくは、UEFI 信頼される実行環境 EFI プロトコルに関するページをご覧ください。

 

ファームウェア ブート マネージャーの要件

ファームウェア ブート マネージャーは、仕様のセクション 3.3 で定義されている既定の起動動作をサポートする必要があります。さらに、マルチブートをサポートするために、グローバル定義の変数と、仕様のセクション 3.1 のブート マネージャーの要件が必要です。

UEFI ARM バインディングの要件

UEFI ARM バインディングには、UEFI 仕様に準拠するために必要な ARM プラットフォームに固有の要件が含まれます。Windows では、ARMv7 に適用される、ARM バインディングのすべての項目が必要です。Windows では、ARMv7 より前の項目はサポートされていないため、ARMv6k 以前の項目に固有のバインディング要件は必須ではありません。

バインディングでは、MMU の構成方法や、物理的なメモリマッピング方法などが指定されます。バインディングでは、UEFI プロトコルおよびサービスへの呼び出しを ARM ISA でのみ実行する必要があることも指定されます。つまり、Thumb2 または Thumb で実行されているソフトウェアは、UEFI 関数を呼び出す前に ARM モードに戻す必要があります。

UEFI ARM マルチプロセッサの起動の要件

Microsoft は、複数の ARM コアをマルチプロセッサ UEFI プラットフォームで起動するためのプロトコルを開発しました。このプロトコルは、Power State Coordination Interface (PSCI)をサポートしていない ARM プラットフォームの Windows で必要です。PSCI をサポートしていないプラットフォームでは、このプロトコルを使用しないでください。このプロトコルの詳細については、ACPI Component Architecture (ACPICA) の Web サイトにある「Multiprocessor startup on UEFI ARM-based platforms」(UEFI ARM ベースのプラットフォームでのマルチプロセッサの起動) ドキュメントをご覧ください。

プラットフォーム セットアップの要件

ファームウェアは、OS ローダーに引き継ぐ前に、システム ハードウェアを明確に定義された状態にする役割を果たします。次の表では、関連するプラットフォーム セットアップの要件を定義しています。

要件 説明
ブート パス ファームウェアは、Windows が UEFI 経由でブート デバイスにアクセスし、カーネルを読み込むことができるポイントまでプラットフォームを初期化する必要があります。ブート デバイスから読み取るための階層構造に関わるすべてのデバイスは、パフォーマンスと電源を考慮して、妥当な速度で計時され、電力供給される必要があります。ベース プロセッサ コア自体も、システムがバッテリを消耗することなく、適切なタイミングで起動できるように、妥当な速度で計時され、電力供給される必要があります。
コア システム リソース

ACPI テーブル経由で OS に公開されているコア システム リソースは、電源をオンにし、計時する必要があります。コア システム リソースには割り込みコントローラー、タイマー、DMA コントローラーが含まれており、これらは OS で管理する必要があります。

さらに、OS で関連付けられているデバイス ドライバーがデバイスで割り込みをマスク解除し、再び有効にするまで、ExitBootServices() への呼び出しによって割り込みをマスクする必要があります。ブート サービス中に割り込みを有効にした場合は、ファームウェアが割り込みを管理すると見なされます。
デバッグ Windows では、USB 3 ホスト (XHCI)、USB 2 ホスト (EHCI)1、IEEE 1394、シリアル、および USB 関数の各インターフェイス (および PCI イーサネット アダプター) によるデバッグがサポートされています。これらの 1 つ以上が、OS に渡される前にファームウェアによって電源供給され、計時され、初期化される必要があります。どれを選択した場合でも、デバッグ用の公開ポートを備えている必要があり、コントローラーは、メモリ マッピング済みであるか、専用 (非共有) の周辺機器バス経由で接続されている必要があります。
その他のプラットフォーム セットアップの要件 ピンの多重化とパッド構成はすべて、OS ローダーにコントロールが渡される前にファームウェアで完了している必要があります。

 

インストール要件

Windows には、GPT パーティション ストレージ ソリューションに存在する OS パーティションが必要です。MBR パーティション ストレージは、データ ストレージとして使用できます。UEFI 仕様で定義されているように、UEFI プラットフォームには、専用のシステム パーティションが必要です。Windows には、EFI システム パーティション (ESP) と呼ばれる、この専用システム パーティションが必要です。

ハードウェア セキュリティ テスト インターフェイス (HSTI) の要件

プラットフォームは、ハードウェア セキュリティ テスト インターフェイスを実装する必要があり、プラットフォームは、ハードウェア セキュリティ テスト可能性仕様に指定されているように、ドキュメントと移行ツールを共有する必要があります。

関連トピック

SoC プラットフォームの Windows 向けの最小 UEFI 要件

Windows 10 Mobile の UEFI 要件

USB フラッシングのサポートの UEFI 要件