共用方式為

SoC 平臺上 Windows 版本的 UEFI 需求

  • 發行項

本文說明適用于傳統型版本的 Windows 10 UEFI 需求， (家用版、專業版、企業版和教育版) 和Windows 10 行動裝置版。 如需僅適用于Windows 10 行動裝置版的其他需求，請參閱Windows 10 行動裝置版 的 UEFI 需求。

需求摘要

下表列出 UEFI 規範的所有目前需求，如 UEFI 規格 (UEFI 2.3.1 規格的第 2.6 節) 所定義。 在此表格中， 明確 Windows 需求 一詞會識別 Windows 元件直接呼叫的任何通訊協定或服務。 雖然只有 Windows 明確使用這些服務，但其他列出的服務和通訊協定可能是核心韌體實作、EFI 設備磁碟機或開發和部署工具鏈結隱含或明確要求。

Microsoft 歡迎實作者對此一組需求的意見反應和意見。 對於作業系統或韌體判斷為不需要的任何 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 系統資料表所指向的組態表必須包含下表所述的兩個 GUID 及其相關聯的指標。

GUID 描述
EFI_ACPI_Table GUID 此 GUID 必須指向平臺的 ACPI 根系統描述指標 (RSDP) 。
SMBIOS_Table GUID 此 GUID 必須指向 SMBIOS 進入點結構。

Windows 需要 2.4 或更高版本的 SMBIOS 規格。 需要第 3.2 節「必要結構和資料」，以及 4「一致性指導方針」。 Windows SMBIOS 相容性測試可供使用。

EFI 開機服務需求

下表列出 Windows 的 EFI 開機服務需求。

EFI 開機服務 需求
記憶體服務 Windows 需要所有記憶體服務。
通訊協定處理常式服務 Windows 需要下列通訊協定處理常式服務：

OpenProtocol ()
CloseProtocol ()
LocateDevicePath ()
LocateHandle ()
影像服務 Windows 需要下列映射服務：

ExitBootServices ()
其他開機服務 Windows 需要下列其他開機服務：

Stall ()

注意： 需要 Stall () 實作，才能有確定性 (可重複的) 錯誤，以便可靠地進行錯誤修正或取消。

EFI 執行時間服務需求

下表列出 Windows 的 EFI 執行時間服務需求。

EFI 執行時間服務 需求
時間服務 Windows 需要下列時間服務：

GetTime ()
SetTime ()

注意： 只有在 ExitBootServices () ) 之前，才會在開機 (期間呼叫時間服務，以存取平臺當日硬體。
變數服務 在系統的目標類別上管理多個開機裝置和安全性變數時，需要所有 UEFI 變數服務。
其他執行時間服務 Windows 需要下列其他執行時間服務：

ResetSystem ()

注意： ResetSystem () 實作必須同時支援重設和關機選項。

通訊協定需求

下表描述 Windows 在開機期間完成特定功能所需的 UEFI 通訊協定。

通訊協定 需求
圖形輸出通訊協定 Windows 需要圖形輸出通訊協定 (GOP) 。 特定的畫面緩衝區需求如下：

針對整合式顯示器， HorizontalResolution 和 VerticalResoluton 必須是面板的原生解析度。

針對外部顯示器， HorizontalResolution 和 VerticalResoluton 必須是顯示器的原生解析度，如果不支援，則視訊介面卡和連接的顯示器都支援的最高值。

PixelPerScanLine 必須等於 HorizontalResolution。

PixelFormat 必須是 PixelBlueGreenRedReserved8BitPerColor。 需要實體框架緩衝區;不支援 PixelBltOnly 。

將執行遞交給 UEFI 開機應用程式時，韌體開機管理員和韌體不得將框架緩衝區用於任何用途。 開機服務結束時，畫面緩衝區必須繼續掃描。
替代顯示輸出 UEFI 韌體必須使用硬體支援的任何顯示連接器來支援開機。 如果內部面板已連接且可見，則必須使用內部面板。 所有實際連接顯示器的輸出都必須顯示開機畫面。 針對連線的顯示器，UEFI 韌體必須：

如果可以判斷原生解析度，請使用顯示器的原生模式初始化輸出。

如果無法進行原生模式，則必須初始化為最高的相容模式。

如果無法判斷顯示器功能，則連線的顯示器必須在已知 (與 640x480 或 1024x768) 的 640x480 或 1024x768 相容的模式中初始化。
開機時輸入 需要 EFI 簡單文字輸入通訊協定，才能在具有內建鍵盤或附加鍵盤的系統上選擇開機或其他功能表選項。 對於無鍵盤的系統，在開機環境中建議使用三個按鈕：

[開始] 按鈕
音量向上按鈕
[向下音量] 按鈕

按鈕按下應該透過 EFI 簡單文字輸入通訊協定回報，方法是分別將它們對應至下列鍵盤按鍵：

Windows 按鍵
向上鍵
向下鍵
本機儲存體開機 Windows 需要包含 EFI 系統磁碟分割和 Windows OS 磁碟分割之儲存體解決方案的區塊 I/O 通訊協定和裝置路徑通訊協定支援。 若要從需要耗用撫平或其他快閃管理的快閃儲存體開機，這必須在韌體中實作， (不在 UEFI 應用程式) 中實作。

安全性需求

Windows 在安全開機、測量開機、密碼編譯和資料保護方面具有安全性需求。 下表詳述這些需求。 此外，對於 SoC 硬體防止符合現有標準 (TPM、RTC 等 ) 的區域，則會開發其他需求。 這些會在資料表結尾描述。

區域 需求
一般

  • 需求 1：強制。 平臺應符合本節中指定的所有需求。

  • 需求 2：強制。 平臺應為 UEFI 類別三，且未安裝或安裝相容性支援模組。 BIOS 模擬和舊版電腦/AT 開機必須停用。
UEFI 安全開機

  • 需求 3：強制。 安全開機，如 UEFI v2.3.1 第 27 節中所定義，必須隨附已啟用且簽章資料庫 (EFI_IMAGE_SECURITY_DATABASE) ，才能安全地預先布建機器。 簽章資料庫的初始內容取決於 OEM，根據必要的協力廠商 UEFI 驅動程式、復原需求和電腦上安裝的 OS 開機載入器，但應包含 Microsoft 提供的EFI_CERT_X509簽章。 不應該有其他簽章。

  • 需求 4：強制。 需要有 UEFI「禁止」簽章資料庫 (EFI_IMAGE_SECURITY_DATABASE1) 。

  • 需求 5：強制。 Microsoft 提供的 UEFI KEK 應該包含在 UEFI KEK 資料庫中。 不應該有額外的 KEK。 Microsoft 會以EFI_CERT_X509簽章的形式提供 KEK。

  • 需求 6：強制。 PK發佈 金鑰應存在並儲存在韌體快閃中。 注意：因為 PKpriv (PKpub 的私密金鑰對應專案，) 控制使用 PK發佈布建之所有裝置上的安全開機原則，因此必須密切保護其保護和使用。

  • 需求 7：強制。 初始簽章資料庫應該儲存在韌體快閃中，而且只能使用 OEM 簽署的韌體更新或透過 UEFI 驗證的變數寫入來更新。

  • 需求 8：強制。 無法執行失敗簽章驗證之開機路徑中的映射，且失敗的原因應新增至EFI_IMAGE_EXECUTION_TABLE。 此外，在這些情況下的建議方法是，UEFI 開機管理員會根據 OEM 特定的策略起始復原。

  • 需求 9：強制。 無法對無法通過簽章驗證的 UEFI 映射，實際呈現使用者覆寫。

  • 需求 10：選擇性。 OEM 可以實作實際呈現使用者關閉安全開機的功能，其可存取 PKpriv 或透過韌體設定使用實體目前狀態。 存取韌體設定可能會受到平臺特定方式的保護， (系統管理員密碼、智慧卡、靜態設定等 )

  • 需求 11：如果實作需求 10，則為強制。 如果安全開機已關閉，則不得存取所有現有的 UEFI 變數。

  • 需求 12：選擇性。 OEM 可以實作實體呈現使用者在韌體設定中的兩種安全開機模式之間選取的功能：「自訂」和「標準」。 自訂模式可讓您有更大的彈性，如下列所示。

  • 需求 13：如果實作需求 12，則為強制。 設定擁有者特定的 PK，即可在自訂模式中重新啟用已停用的安全開機。 系統管理應依照 UEFI 規格 v2.3.1：韌體/OS 金鑰交換的第 27.5 節所定義繼續進行。 在自訂模式中，裝置擁有者可以在簽章資料庫中設定其選擇的簽章。

  • 需求 14：實作需求 12 時為強制。 韌體設定應該指出是否已開啟安全開機，以及其是否以標準或自訂模式運作。 韌體設定應該提供從自訂到標準模式傳回的選項。

  • 需求 15：強制。 如果韌體設定重設為原廠預設值，則應該清除所有自訂設定的受保護變數，並重新建立原始 PK發行 庫以及原始製造商布建的簽章資料庫。

  • 需求 16：強制。 驅動程式簽署應該使用 Authenticode 選項 (WIN_CERT_TYPE_PKCS_SIGNED_DATA) 。

  • 需求 17：強制。 支援EFI_IMAGE_EXECUTION_INFO_TABLE (，也就是在開機) 期間啟動或未啟動映射的相關資訊建立和儲存。

  • 需求 18：強制。 支援已授權和禁止簽章資料庫的 getVariable () EFI_IMAGE_SECURITY_DATABASE () 。

  • 需求 19：強制。 支援EFI_IMAGE_SECURITY_DATABASE (授權和禁止簽章資料庫) 的 SetVariable () ，使用 Microsoft KEK 進行驗證。

  • 需求 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 通訊協定中所定義介面的平臺上，PK發行 集的摘要應延伸至 TPMPC[03] 作為EV_EFI_VARIABLE_CONFIG事件。

    • 授權簽章資料庫內容的摘要 (請參閱 UEFI 規格 v2.3.1) 清單的第 27.8 節，必須在測量開機中擴充為EV_EFI_VARIABLE_CONFIG事件。 擴充作業應為 TPMPC[03]。

    • UEFI 用戶端可以使用 EFI_IMAGE_SECURITY_DATABASE 變數讀取和剖析憑證清單，並針對擴充值驗證摘要。

    • TCG_PCR_EVENT摘要值應該是 SHA-256，而不是 SHA-1。

  • 需求 24：強制。 平臺必須實作 TCG 平臺重設攻擊風險降低規格中定義的 MemoryOverwriteRequestControl。
密碼編譯

  • 需求 25：強制。 平臺應提供 EFI_HASH_PROTOCOL (UEFI v2.3.1 第 27.4 節) ，以卸載密碼編譯雜湊作業。 必須支援 SHA-256。

  • 需求 26：強制。 平臺應支援 Microsoft 定義的 EFI_RNG_PROTOCOL ，以讀取 Entropy 的預先 OS。
資料保護

  • 需求 27：強制。 平臺必須支援 EFI 變數，並設定下列 UEFI 變數屬性的任何組合：

    • EFI_VARIABLE_BOOTSERVICE_ACCESS

    • EFI_VARIABLE_NON_VOLATILE

    • EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
其他安全性需求

Windows 在 SoC 平臺上需要下列額外需求。

  • Microsoft 已定義從 UEFI 平臺收集 Entropy 的通訊協定。 雖然不是 UEFI 需求，但 SoC 平臺上的 Windows 需要此通訊協定。 如需此通訊協定的詳細資訊，請參閱 UEFI Entropy 收集通訊協定。

  • UEFI 簽章資料庫更新。 UEFI 2.3.1 第 27 節已採用更新已驗證變數的新機制。 Windows 需要此機制。

  • 信任的執行環境。 Microsoft 已開發 EFI 通訊協定來與信任執行環境 (TrEE) 互動，類似于信賴運算群組 (TCG) Trusted Platform Module (TPM) 的子集功能。 EFI 通訊協定會利用信賴運算群組在 2006 年 6 月 9 日 1.2 版 1.00 版的「TCG EFI 通訊協定」大規模運用。

    如需詳細資訊，請參閱 UEFI 信任的執行環境 EFI 通訊協定。

韌體開機管理員需求

韌體開機管理員必須支援規格第 3.3 節中定義的預設開機行為。 此外，若要支援多重開機，則需要全域定義的變數，以及規格第 3.1 節的開機管理員需求。

UEFI Arm 系結需求

UEFI Arm 系結包含需要之 Arm 平臺的特定需求，才能符合 UEFI 規格。 Windows 需要 Arm 系結中適用于 ARMv7 的所有專案。 因為 Windows 不支援 ARMv7 之前的任何專案，所以系結中對於 ARMv6k 和以下系結的需求是選擇性的。

例如，系結會指定如何設定 MMU，以及如何對應實體記憶體。 系結也會指定只應在 Arm ISA 中完成對 UEFI 通訊協定和服務進行的呼叫，這表示在 Thumb2 或 Thumb 中執行的軟體必須在呼叫 UEFI 函式之前切換回 Arm 模式。

UEFI Arm 多處理器啟動需求

Microsoft 已開發通訊協定，以在多處理器 UEFI 平臺上啟動多個 Arm 核心。 不支援 Power State 協調介面 (PSCI) 的 Windows 在 Arm 平臺上需要此通訊協定。 支援 PSCI 的平臺不得使用此通訊協定。 如需此通訊協定的詳細資訊，請參閱 ACPI 元件架構 (ACPICA) 網站的 UEFI Arm 平臺多處理器啟動 檔。

平臺設定需求

韌體負責將系統硬體置於妥善定義的狀態，然後再將系統硬體交給 OS 載入器。 下表定義相關的平臺設定需求。

需求 描述
開機路徑 韌體必須將平臺初始化為 Windows 能夠透過 UEFI 存取開機裝置並載入核心的位置。 根據效能和電源考慮，從開機裝置讀取階層所涉及的任何裝置都必須以合理的速率來時鐘和電源。 基底處理器核心本身也應該以合理的速率時鐘和電源，讓系統可以及時開機，而不需要清空電池。
核心系統資源 透過 ACPI 資料表公開給 OS 的核心系統資源必須開啟並時鐘。 核心系統資源包括必須由作業系統管理的中斷控制器、計時器和 DMA 控制器。 此外，必須透過呼叫 ExitBootServices () 來遮罩中斷，直到 OS 中相關聯的設備磁碟機解除遮罩並重新啟用裝置上的中斷為止。 如果在開機服務期間啟用中斷，則會假設韌體會管理它們。
偵錯 Windows 支援透過 USB 3 主機 (XHCI) 、USB 2 主機 (EHCI) 1、IEEE 1394、序列和 USB 函式介面 (進行偵錯，以及 PCI 乙太網路卡) 。 在 OS 交接之前，至少必須由韌體提供電源、時鐘和初始化其中一項。 無論提供哪一個選項，都必須有公開的埠以進行偵錯，而且控制器必須經過記憶體對應，或透過專用的 (非共用) 周邊匯流排連線。
其他平臺設定需求 任何針腳多工處理和麵板設定都必須在韌體中完成，才能將控制權交給 OS 載入器。

安裝需求

Windows 需要 OS 磁碟分割位於 GPT 磁碟分割儲存解決方案上。 MBR 分割儲存體可作為資料儲存體。 如 UEFI 規格中所定義，UEFI 平臺需要專用的系統分割區。 Windows 需要這個專用的系統分割區，稱為 EFI 系統分割區 (ESP) 。

HSTI (硬體安全性測試介面) 需求

平臺必須實作硬體安全性測試介面，而且平臺必須共用硬體 安全性測試規格中指定的檔和工具。

SoC 平臺上 Windows 的最低 UEFI 需求

Windows 10 行動裝置版的 UEFI 需求

USB 快閃支援的 UEFI 需求