UEFI架構

在上兩篇UEFI的文章中，大家應該對什麼是UEFI有了整體性的把握，這裡我們一起來了解下UEFI的整體架構。這篇文章建立在前面兩篇UEFI介紹文章和安全啟動文章的基礎上。

UEFI架構

UEFI提供系統化的標準方法，載入驅動並管理他們之間的交互。

UEFI 提供了一個標準介面，以便在硬體發生變更時固件能提供足夠信息而保證操作系統不受影響。它包含有晶元組和外設晶元驅動程序，並通過系統表提供引導時服務和運行時服務。

圖一中展示了依賴於UEFI所提供的服務來工作的操作系統裝載器（即 EFI OS Loader） 是如何啟動操作系統內核的。其他工業標準介面，如ACPI和SMBIOS等，和UEFI也是並行不悖的。

UEFI提供了一個有序的方法來載入驅動程序和處理它們之間的相互依賴性。當必要的驅動程序被載入後，引導管理器或調度器會嘗試（查詢）一系列預配置好的引導路徑或引導設備。在進行該操作時，一個調用了UEFI引導時服務的文件會被載入和執行。這個文件的載入操作是確保安全的一個重要支撐點，如果你看過我們以前的文章，就會反應過來，它就是——安全引導（Secure Boot）。

如果引導失敗，會返回到UEFI引導管理器對此進行處理。但我們，一旦引導程序試圖執行退出UEFI引導時環境的OS引導載入程序，那這個退出的引導時環境不能再次進入（re-entered），如圖二所示。

服務

1。引導時服務

下表顯示了UEFI應用程序可用的引導時服務類別。其中最重要的是以映像處理為主的服務，因為它是載入和執行模塊的必由之路。

2。運行時服務

下表展示了在UEFI環境中可用的運行時服務類別。這些調用（calls）可以修改易失性數據，非易失性數據和實時時鐘設置，從而改變平台的狀態。平台狀態的控制則是平台安全性方面的另一個重要領域。

UEFI的早期版本（如UEFI2.0）幾乎不提供安全服務。比如：不提供保存平台數據的安全方法（保證只有數據的創建者可以進行數據的修改或刪除操作）；沒有提供基本的身份驗證工具，如散列或解密功能。問題的發現為增強UEFI環境安全性指明了研究方向，一個涉及增強UEFI安全能力（安全啟動），另一個涉及測量和記錄平台狀態（可信計算）。

基礎實現

首先來看一個小問題：implement，都知道是實現的意思，那究竟什麼算實現，何種程度可以稱之為實現呢？我們首先來理解這個詞，這樣會對後面的內容有所幫助。以下內容來自維基百科：在計算機科學中，實現是作為程序，軟體組件或通過計算機編程和部署的其他計算機系統的技術規範或演算法的實現。 對於給定的規範或標準可能存在許多實現。 例如，web瀏覽器包含萬維網聯盟推薦的規範的實現，軟體開發工具包含編程語言的實現。或許看完這段你會有所理解，簡言之：實現是且僅指規範的軟體實現。接下來，我們開始講針對於UEFI規範的實現。

儘管前面我們大講UEFI各個方面，實際上，UEFI建立在被稱為平台初始化（Platform Initialization，簡稱PI）標準的框架之上。PI標準為前期硬體初始化提供了標準流程和架構。此處我們討論PI安全問題中與UEFI相關的方面。

按照UEFI設計者們的想法，UEFI應當可以從系統中的任意位置發現和運行文件（這是老舊的BIOS無法做到的）。 以下是這一特性如何實現的功能概述，以及在引導過程中，文件載入背後潛藏的安全風險。

1。SEC，PEI和DXE

PI規範允許基於UEFI的系統遵循標準固件架構。 這種系統的引導過程包括一系列階段。 每個階段既有自己獨特的安全優勢，也包含著不同的風險。

PI平台啟動的安全（Security，簡稱SEC）階段必須處理不同類型的平台重置（Reset）事件。 SEC還是系統的信任根，它為系統上進一步啟動固件提供了控制點（Control Point）。 SEC階段的優點在於：它可以提供一個錨點，基於這個錨點來構建一個已驗證的引導過程。一旦臨時存儲器可用，SEC必須找到引導進程的下一個階段：EFI預初始化（Pre-EFI Initialization簡稱PEI）階段，並將控制許可權移交。當然，根據PEI代碼的位置以及平台策略，PEI代碼必須在執行之前經過認證。

PEI階段的目標是為PEI模塊的執行搭建合適的環境。 因此，在PEI階段初期，PEI調度器就已啟動。 PEI模塊通常對設備和晶元組的底層平台進行初始化，例如串列埠和內存的初始化。 該階段的的另一個職責是搜索平台信息，在切換塊（hand-off blocks，簡稱HOB）中為此信息創建資料庫，並將資料庫傳遞給平台引導的下一階段：DXE階段。 和上一階段相同的是，PEI模塊也必須在運行模塊之前進行驗證。 一般來說，PEI模塊是平台的核心固件的一部分，並且對於特定平台模型，可以認為這個模塊是靜態且可信的。 不過，在PI規範中沒有關於PEI模塊位置的要求，因此可以存在其中一些或所有PEI模塊將需要被認證以維持平台完整性的平台。有些平台為了維持其完整性，會對所有的PEI模塊進行驗證。

當PEI階段找到並開始執行DXE的初始化程序載入時，標誌著引導程序進入了PI規範要求的最終階段。DXE階段通過HOB來查詢平台的相關信息，並為驅動程序搭建一個更加完整的環境。 DXE調度程序負責查找和啟動DXE驅動程序，這些驅動程序可能有很多來源。但PI代碼和UEFI核心僅來自系統板製造商，並且不能由第三方任意擴展。平台製造商必須為符合PI規範而且採用了UEFI服務的固件負責，保障其從生產到交付後的真實性和安全性。 為了保持平台完整性，對固件的更改必須處於平台製造商的控制監督之下。在不同的平台下，這一控制的實現或許會有所不同，但不管是什麼平台，都必須實現散列和加密認證等方式，否則其安全性無法得以真正保障。 在較新版本的UEFI規範（從哪一版開始？）中，都提供了一些用於固件更新的工具。 對安全引導來說，固件更新必須是受控的（如何實現這一要求在本公眾號的前幾期文章有講到，看過的讀者不妨回憶一下）。固件受控對於TCG測量引導（TCG Measured Boot）也同樣必要。

科普幾個名詞，可信計算組（Trusted Computing Group，簡稱TCG），與其相關的標準名字很簡單，就叫TCG標準，該標準中定義了這樣一個名詞：受信操作的核心根（Core Root of Trust for Measurement，簡稱CRTM）。 實現CRTM的一種方法是使用靜態CRTM（Static CRTM，S-CRTM），它是位於系統附帶的快閃記憶體部分中的核心平台固件。 S-CRTM負責檢測在S-CRTM之後執行的任何代碼。 不要認為它與安全引導的職責是相同的，測量引導僅提供所有運行過的固件模塊的記錄，並且不提供有關固件模塊完整性的任何判斷，簡言之就是：只記錄，不負責。

2。BDS，OS loader和RT

在DXE結束後，BDS得以運行。BDS（Boot Device Select），顧名思義，就是發現引導設備（全部或者部分），並作出選擇（用戶選擇或者根據設定）。它負責初始化所有啟動OS所需的設備（輸入、輸出和存儲）。在更高層面上講，它負責執行所有符合UEFI驅動模型（UEFI driver model）的驅動。這是一個發現並一個個連接的過程。譬如，首先發現PCI root，接著發現PCI bus，在PCI bus下發現SATA controller和USB controller。。。一個個啟動設備被發現，其設備路徑（device path）也被連接起來。在萬事俱備後，一個界面被顯示出來（嵌入式系統上可以沒有），供用戶進行設置和選擇啟動設備，這就是大家熟悉的BIOS界面。

在用戶選擇或者用預設的設備被挑出來後，BDS載入OS loader，而OS loader負責找到並運行OS。在OS啟動後，所有的啟動時服務都不可用了，只有運行時服務得以留存。

後記

希望閱讀完後讀者能對UEFI有了整體的把握，如果還能提升你對UEFI的興趣，想去更深入的了解和學習，那我們將不勝榮幸。

UEFI歷史和架構其他文章：

UEFI和UEFI論壇 - 知乎專欄

UEFI背後的歷史 - 知乎專欄

ACPI與UEFI - 知乎專欄

UEFI安全啟動 - 知乎專欄

UEFI與硬體初始化 - 知乎專欄

UEFI架構 - 知乎專欄

歡迎大家關注本專欄和用微信掃描下方二維碼加入微信公眾號"UEFIBlog"，在那裡有最新的文章。同時歡迎大家給本專欄和公眾號投稿！