作者：Michael Rothman，Vincent Zimmer

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

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

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

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

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

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

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

國際金融機構規范

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

平臺初始化 （PI） 規范

定義如何構建底層平臺固件。

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

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

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

圖1 固件源樹產品的演變

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

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

關于攻擊的類別，市場上已經觀察到很多。其中包括早期 PI 或更高版本的 DXE 流中的特權提升、錯誤的選項 ROM（旨在初始化特殊設備），甚至是攻擊硬件。針對固件的攻擊類別的示例可以在下面的圖 3 中看到。

圖3 固件攻擊的分類

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

圖 4 UEFI 固件的供應鏈

主機固件的作用是什么？

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

圖 5 UEFI PI 固件的啟動流程

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

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

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

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

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

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

圖 7 膠囊更新啟動流程

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

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

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

審核編輯：郭婷