作者：Michael Rothman，Vincent Zimmer

在本文中，我們將介紹以安全、可管理和可觀察的方式在現場更新基于計算的平臺的方法。

在整篇文章中，我們還將介紹存在哪些底層組件來實現所有這些工作，特別是在基于 UEFI 的固件實現Beyond BIOS 的上下文中。

讓我們從“平臺固件”開始，在這種情況下，平臺固件由嵌入式邏輯定義，該邏輯有助于初始化平臺硬件并啟動引導目標。此固件通常駐留在計算機的主板上，甚至駐留在插件設備（如存儲控制器和網絡設備）上的芯片上。

最終，平臺啟動固件的要點是啟動目標軟件，通常是操作系統。

從歷史上看，啟動固件沒有一組可跨平臺、第三方硬件和操作系統域互操作的標準化應用程序編程接口 （API）。這些組件中的每一個都有自己的編程孤島，幾乎沒有標準交互。

然而，在2005年，UEFI（統一可擴展固件接口）論壇成立。其主要目標之一是為機器內的組件如何相互通信提供行業標準。

簡而言之，UEFI 論壇涵蓋三個主要規范：

UEFI 規范

平臺與第三方內容（如操作系統或插件設備）之間的 API 集。

平臺初始化 （PI） 規范

定義如何構建基礎平臺固件。

高級配置和電源接口 （ACPI） 規范

定義從平臺到操作系統的不可發現信息和運行時交互的抽象。

如上所述，固件執行許多角色。固件的實施基于行業標準，例如 UEFI PI 規范。PI 階段包括預 EFI 初始化 （PEI） 和驅動程序執行環境 （DXE）。通常，一個平臺可能有 50 個 PEI 模塊和 180 個 DXE 模塊。構建這些元素的源代碼樹可以包含數十萬行 C 代碼，隨著產品的發布，將策劃各種分支，如圖 1 所示。

圖1 固件源碼樹產品的演進

這些模塊和驅動程序都在環 0 內執行，并且通常沒有組件間分離，這在操作系統中的應用程序中很常見。因此，任何組件中的缺陷都可能導致平臺的潛在危害。其中許多組件使用攻擊者控制的輸入，例如磁盤上的數據結構、操作系統設置的 UEFI 變量等策略對象以及來自未受保護總線的輸入。如此大量的可執行代碼具有許多攻擊面，隨著新技術的引入，會創建更多面。對 UEFI 固件實現必須支持的各種標準的支持會增加復雜性。這些標準的演變見下文圖2。

圖2 固件支持的規格和標準的演變

關于攻擊的類別，市場上已經觀察到許多攻擊。其中包括權限升級到早期 PI 或以后的 DXE 流、錯誤的選項 ROM（旨在初始化特殊設備），甚至攻擊硬件。針對固件的攻擊類示例如下圖 3 所示。

圖3 固件攻擊分類

通過UEFI論壇和開源社區建立了報告機制，以支持負責任地披露這些安全問題。然而，挑戰在于分散的供應鏈。例如，EDKII 代碼在tianocore.org上的使用需要經過許多人的處理，例如開源到芯片供應商、芯片供應商到原始設備制造商 （OEM） 以及 OEM 到原始設備制造商 （ODM）。例如，TianoCore 中的缺陷如何最終在其系統上的最終用戶閃存 ROM 中為由 ODM 生成的設備進行更新？當今供應鏈和修補的復雜性可以在下面的圖 4 中得到證明。

圖4 UEFI固件供應鏈

主機固件的作用是什么？

引導固件分階段初始化，包括 PEI 和 DXE，如圖 5 所示。

圖5 UEFI PI固件啟動流程

在 （DXE） 驅動程序執行環境中，我們枚舉平臺上的設備，然后執行邏輯來初始化這些設備。有時，如果這些設備眾所周知并符合某些標準，則這些設備可能在固件中具有內置支持，而其他設備可能具有設備攜帶的初始化代碼，并且反過來由固件啟動。

在后一種情況下，設備的初始化代碼通常會公開固件管理協議 （FMP） 接口，如果需要，該接口可用于現場更新。

固件初始化的最后階段是操作系統加載程序通過 UEFI API 與固件交互并促進其自身的初始化。它還可以通過各種方式執行固件更新，例如基于膠囊的更新。

如前所述，固件更改可能會穿過芯片供應商、固件供應商、OEM 和 ODM 供應鏈的曲折路徑，出現在最終用戶系統中。從歷史上看，這些當事方中的許多都有自定義更新工具，這些工具必須安裝到各種操作系統和獨特的位置中才能發現和下載更新。這種蒙昧主義的空間，即如何更新您的設備，通常導致許多最終用戶不維修他們的設備并及時更新他們的固件。

進入 UEFI 膠囊。UEFI 膠囊包含各種元素，包括將更新本身的二進制封裝到稱為 UEFI 膠囊的東西中。UEFI 膠囊具有由全局唯一標識符 （GUID） 命名的明確定義的標頭。系統固件的生產者將其更新有效負載（無論是代碼、數據還是更新驅動程序）包裝為此格式。然后，通過使用膠囊生產者擁有的密鑰材料在膠囊中應用加密簽名來保證更新的來源。

使用膠囊后，OS 可以通過引用 EFI 系統資源表 （ESRT） 來確定平臺是否支持此膠囊類型，該表 （ESRT） 是一系列指定平臺中的版本和可能可更新元素的 GUID。如果手頭的膠囊 GUID 與 ESRT 條目匹配，則操作系統可以暫存，或者預操作系統 UEFI 應用程序將使用上述膠囊二進制文件作為參數發出 UpdateCapsule（） UEFI 運行時調用。Linux 和 Windows 通常通過將膠囊復制到操作系統前的可訪問位置（如 EFI 系統分區 （ESP））并重新啟動來暫存更新。重新啟動后，UEFI OS 加載程序可以發出 UpdateCapsule（） 調用，設備將重新啟動。在重新啟動期間，UEFI PI 代碼將確定膠囊位置，可能合并，加密驗證，如果真實，則使用更新更新閃存。整體流程如下圖所示 7。

圖 7 膠囊更新啟動流程

更新發生后，可能會對系統穩定性有一些擔憂。因此，UEFI ACPI 規范中有一些功能，例如平臺運行狀況評估表 （PHAT），可以查詢以查看系統狀態是否有任何意外更改。更新還會影響系統完整性，如平臺配置寄存器 （PCR） 中的更改所示。因此，在更新之前，操作系統可能需要解封機密，發布更新，然后針對最新的 PCR 重新密封。

為了促進生態系統創建膠囊，TianoCore / EDK2資源提供了一個模板，用于創建基于UEFI固件管理協議的更新驅動程序，創建ESRT條目，簽名等。生態系統中還支持使用Linux供應商固件服務（LVFS）和Windows Update（WU）管理Linux中的膠囊更新。鑒于鏈的強度取決于其最薄弱的環節，因此可以在構建安全固件中找到有關構建高保證固件的一些最佳實踐。

總之，本文討論了以安全、可管理和可觀察的方式執行固件更新的方法。這些屬性通過基于 UEFI 的固件中的基礎結構啟用，包括基于加密的膠囊、PHAT 和 FMP 協議。

審核編輯：郭婷