引言

在探討了解學習虛擬化的安全方案（如HyperEnclave）時，我們經常會遇到動態信任根（DRTM）的概念。但DRTM的有效性，又依賴于一個穩固的靜態信任根（Static Root of Trust for Measurement, SRTM）。這條SRTM信任鏈，構成了整個平臺可信度的基石。

本文檔的目的，就是完整地、系統性地梳理這條信任鏈。我們將從PC上電的瞬間開始，一路追蹤信任的“接力棒”是如何從UEFI固件，傳遞給GRUB 2引導加載程序，并最終由Linux內核接管，將其延伸至每一個運行中的應用程序。

---

一、 可信根基：TPM與核心概念

在深入流程之前，必須先對齊幾個貫穿始終的核心概念。

1.1 什么是“度量” (Measurement)？

在可信計算的語境里，“度量”就是一個動作：對一段數據（比如一個文件或一段代碼）計算其密碼學哈希值（如SHA-256）。

這個哈希值就像是這段數據的“數字指紋”，任何微小的改動都會導致指紋發生天翻地覆的變化。這個動作本身不提供安全，它只是提供了一種可驗證的、唯一的身份標識。

1.2 信任鏈與TPM PCR

“信任鏈”（Chain of Trust）的思想很簡單：信任是需要傳遞的。就像接力賽，第一棒運動員（信任的根源）必須是可信的，然后他把接力棒（控制權）交給第二棒時，必須先保證第二棒也是可信的。

TPM（可信平臺模塊）就是這個過程中的“公證員”和“記事本”。它內部有一組特殊的寄存器，叫平臺配置寄存器（Platform Configuration Registers, PCRs）。

PCR有一個獨一無二的特性：你不能直接寫入一個值，你只能對它執行Extend（擴展）操作。

Extend操作的本質是：PCR_new_value = HASH(PCR_old_value || new_data_hash)

這個特性使得PCR成為了一個完美的、防篡改的啟動日志。任何對啟動流程的偏離，都會在這本“只能追加、不能修改”的日志上留下清晰的痕跡。

---

二、 階段一：固件的可信啟動 (UEFI)

信任鏈的源頭，始于PC上電后運行的第一行代碼——UEFI固件。它的啟動過程并非一個單一步驟，而是遵循業界標準（如PI-Spec）的一個分階段的初始化序列。

2.1 引導的起點：從SEC到DXE的初始化

UEFI的啟動可以大致分為幾個關鍵階段，每一步都為下一步構建基礎。

圖1: UEFI 啟動階段總覽

1. SEC (Security) Phase - 安全階段:

• 這是CPU在加電后執行的第一段代碼，通常由處理器的微碼和固件中的一小段匯編代碼組成，是平臺的靜態信任根度量（Static Root of Trust for Measurement, SRTM）的起點，也被稱為核心信任根度量（Core Root of Trust for Measurement, CRTM）。

• 它的核心任務非常單純：建立一個臨時的運行環境（通常是使用CPU的緩存作為臨時內存），并找到、驗證、啟動下一階段（PEI）。作為信任鏈的第一環，它會度量PEI階段的代碼，并將結果Extend到 PCR[0] 中。

2. PEI (Pre-EFI Initialization) Phase - EFI前期初始化階段:

• PEI的主要職責是初始化主內存（DRAM）。一旦DRAM可用，后續的復雜任務才有了運行空間。

• 它會進行最核心的平臺硬件發現（如CPU、芯片組），并將這些信息組織成一個“交接清單”（Hand-Off Block List, HOBs），傳遞給下一階段。在交接前，它會度量DXE階段的核心代碼，并繼續Extend到 PCR[0]。

3. DXE (Driver Execution Environment) Phase - 驅動執行環境階段:

• 這是UEFI的“主舞臺”。DXE階段的核心是一個分發器（Dispatcher），它會根據依賴關系，循環加載和執行一系列的DXE驅動，完成對平臺上幾乎所有硬件的初始化。

• 在這個階段，各種UEFI服務和協議被創建和發布，比如文件系統服務、塊設備I/O服務，以及我們可信啟動所依賴的 TPM服務協議（EFI_TCG2_PROTOCOL）。所有被加載的DXE驅動，也都會被度量并繼續Extend到 PCR[0]。到DXE階段結束時，系統已經是一個功能完備的“小型操作系統”。

2.2 引導設備選擇 (BDS)：UEFI如何找到GRUB

DXE階段完成后，控制權交給BDS（Boot Device Selection）階段。這本質上就是我們熟知的UEFI啟動管理器。在執行引導加載程序之前，BDS自身也會被度量到PCR[0]中，至此，PCR[0]完整地記錄了整個固件的啟動鏈條。

1. 讀取NVRAM啟動變量:

• BDS會讀取主板上非易失性存儲器（NVRAM）中存儲的啟動變量。最重要的變量是 BootOrder，它定義了啟動項的嘗試順序，如 [Boot0001, Boot0002, Boot0000]。

• 每一個啟動項（如Boot0001）都是一個詳細的記錄，它包含了：

• 設備路徑: 指向一個具體的物理設備（如某一塊硬盤的某個分區）。

• 文件路徑: 指向該設備上要執行的EFI應用程序的路徑。

• 描述: 一個用戶可見的字符串，如 “ubuntu” 或 “Windows Boot Manager”。

2. 定位GRUB:

• BDS會按照BootOrder的順序，嘗試加載第一個啟動項。例如，對于Boot0001 (“ubuntu”)，它會根據設備路徑找到ESP分區（EFI System Partition，一個標準的FAT32分區），然后在這個分區上根據文件路徑找到GRUB的核心鏡像，例如 \EFI\ubuntu\grubx64.efi。

• 備用路徑(Fallback Path): 如果所有BootOrder中的啟動項都失敗了，或者BootOrder為空，BDS會嘗試一個標準的備用路徑：\EFI\BOOT\BOOTX64.EFI。

2.3 Secure Boot與度量：信任的第一次傳遞

在BDS最終決定要執行某個EFI應用程序（如grubx64.efi）的那一刻，Secure Boot和TPM度量機制會介入，完成信任的第一次傳遞。

1. Secure Boot驗證:

• 在執行grubx64.efi之前，UEFI會用其內置的**簽名數據庫（db）**中的公鑰，去驗證這個文件的數字簽名。

• 同時，它會檢查這個文件的簽名哈希是否位于**禁止簽名數據庫（dbx）**的黑名單中。

• 只有簽名有效且不在黑名單中，程序才被允許執行。

2. 第一環度量:

• 在驗證簽名的同時，UEFI固件也扮演了第一個度量者的角色。它會度量啟動過程中加載的關鍵組件，并將哈希值擴展到PCR中：

• PCR[0]: 度量UEFI固件自身的核心代碼、啟動設置等。

• PCR[2]: 度量加載的第三方UEFI驅動或擴展ROM。

• PCR[4]: 度量被選中的引導加載程序（如grubx64.efi）的完整鏡像。

• PCR[7]: 度量Secure Boot的策略和密鑰狀態。

3. 交接控制權:

• 至此，在將控制權交給GRUB之前，UEFI已經完成了兩件大事：通過簽名驗證了GRUB的身份合法性，并通過度量記錄下了GRUB的數字指紋。然后，它才會真正跳轉到grubx64.efi的入口點開始執行。

2.4 SEC階段如何與TPM交互？

一個關鍵問題是：在SEC階段，主內存（DRAM）都尚未初始化，系統環境極其簡陋，它怎么可能有TPM的“驅動”來操作寄存器呢？

答案是：它沒有現代意義上的“驅動”，它擁有的是更底層的、固化在自身代碼中的“直接操作能力”。

• CRTM的特殊身份: SEC階段執行的代碼，即核心信任根度量（CRTM），不是一個通用的程序。它是由芯片或主板制造商編寫的、高度特權化、平臺專屬的一小段代碼。它被認為是隱式可信的，是信任的絕對源頭。

• 硬編碼的通信能力: CRTM的代碼直接包含了與TPM芯片進行最低級別通信所需要的所有指令。它知道要通過哪個總線（如LPC或SPI總線）、向哪個具體的I/O端口或內存映射地址（MMIO）發送什么樣字節序列，來命令TPM執行“擴展PCR[0]”這個動作。這個最原始的“TPM驅動”被**硬編碼（Hard-coded）**在了CRTM內部。

• 設計的安全性: 正因為它不依賴任何外部加載的驅動，所以它的行為是確定的、不受外部環境影響的，這恰恰是作為信任根所必需的。

---

三、 階段二：引導加載程序的接力 (GRUB 2)

現在，信任鏈的接力棒傳遞到了GRUB 2手中。

3.1 GRUB自我喚醒并延續信任鏈

GRUB 2的核心鏡像（core.img）已經在內存中運行，但它非常小，功能有限。它需要找到自己的“大部隊”——配置文件和各種模塊。

1. GRUB的自我定位與配置加載:

• GRUB現在是“醒著”的。它會啟用自己內置的、微型的文件系統驅動（例如fat.mod可能已經嵌入core.img中），更重要的是，它會加載更強大的文件系統驅動（如ext4.mod）。

• 它根據安裝時配置的“前綴”（prefix）信息，去另一個分區（通常是Linux的/boot分區，格式為ext4等）下的/grub/目錄中，尋找并讀取它的“施工圖紙”—— grub.cfg 文件。這個文件包含了所有啟動菜單項和要執行的命令。

2. 解析配置并度量:

• GRUB開始逐行解析grub.cfg。當它遇到一個被選擇的menuentry（啟動項）時，它會嚴格按照里面的命令執行。一個用于可信啟動的配置片段可能如下：

menuentry 'Arch Linux (Trusted Boot)' {# 1. 動態加載TPM模塊，讓GRUB具備與TPM交互的能力insmod tpm# 2. 加載Linux內核。加載tpm.mod后，# linux命令會自動觸發度量行為linux /boot/vmlinuz-linux root=UUID=... ro quiet# 3. 加載initramfs。同樣，會被度量initrd /boot/initramfs-linux.img}

• 度量grub.cfg本身: GRUB會度量它解析的這些命令文本，并將結果擴展到PCR中（如PCR[8]），以確保配置本身未被篡改。

• 度量內核: 當執行linux命令時，GRUB首先將/boot/vmlinuz-linux文件完整讀入內存，對其內容進行哈希計算（度量），然后通過tpm.mod將哈希值Extend到指定的PCR寄存器中（通常也是PCR[8]或PCR[10]）。

• 度量initramfs: 同樣，initrd命令也會觸發對/boot/initramfs-linux.img的度量，并將哈希值擴展到PCR中。

圖2：GRUB 2 度量內核的詳細流程

3.2 控制權的第二次交接 (GRUB -> Kernel)

完成所有度量后，GRUB將CPU的控制權正式交給內核的入口點。信任鏈的接力棒，至此成功傳遞給了操作系統。

---

四、 階段三：內核的全面守護 (IMA)

當內核開始運行時，信任鏈并沒有結束，而是進入了一個更精細、更持續的階段。Linux內核通過**完整性度量架構（Integrity Measurement Architecture, IMA）**來接管度量的職責。

4.1 IMA簡介：將信任擴展到整個文件系統

IMA的目標，是將信任鏈從啟動階段的幾個關鍵文件，延伸到系統運行過程中訪問的每一個文件（包括應用程序、配置文件、庫文件等）。

4.2 IMA-Measure：運行時度量

這是IMA最基礎的功能。它的工作流程如下：

圖2: IMA 度量流程

• 鉤子 (Hook): IMA在內核的關鍵路徑（如文件打開、執行execve、內存映射mmap）上設置了鉤子。

• 度量: 每當有文件要被訪問或執行時，鉤子被觸發，IMA子系統會先計算該文件的哈希值。

• 擴展: 計算出的哈希值被擴展到 PCR[10]（IMA專用的PCR寄存器）。

• 記錄日志: 同時，IMA會將這次度量的詳細信息（文件名、哈希值）記錄在內存中的一個日志里，該日志可以通過/sys/kernel/security/ima/ascii_runtime_measurements查看。

通過這個機制，任何在系統運行時被加載的文件，都會留下“指紋”，確保了系統的動態可審計性。

4.3 IMA-Appraise：運行時強制訪問控制

IMA-Appraise是IMA的進階功能。它不僅度量，還會進行強制性的驗證。

• 系統會預先為所有可信文件計算哈希，并將這些哈希值作為擴展屬性（security.ima）存儲在文件元數據中，并進行簽名。

• 當IMA-Appraise啟用時，每次文件被度量后，IMA會：

1. 檢查文件是否有security.ima屬性。

2. 驗證屬性中的哈希簽名是否有效。

3. 比較實時計算的哈希值與屬性中存儲的“黃金哈希值”是否一致。

• 只有三者全部通過，才允許訪問。否則，直接拒絕！ 這將可信啟動從一個“只記錄、不阻止”的模型，變成了一個主動防御的強制訪問控制系統。

---

五、 總結：一條完整的靜態信任根 (SRTM) 鏈

綜上所述，一條完整的Linux靜態信任根鏈條，是一個分工明確、層層遞進的接力過程：

| 階段 | 負責組件 | 核心動作 | 主要度量目標 | 主要影響的PCR |

| :— | :— | :— | :— | :— |

| 階段一 | UEFI 固件 | Secure Boot驗證、度量 | 固件代碼、擴展ROM、引導加載程序 | PCR[0-7] |

| 階段二 | GRUB 2 | 解析配置、度量 | grub.cfg命令、內核、initramfs | PCR[8-9] |

| 階段三 | Linux 內核 (IMA) | Hook關鍵路徑、度量 | 應用程序、庫、配置文件等 | PCR[10] |

從硬件上電到每一個應用被執行，每一步的控制權交接都伴隨著“驗證”與“度量”，確保了信任從一個絕對可信的硬件根（TPM），一路傳遞到運行中的整個操作系統，最終形成了一個堅實、可審計、可驗證的安全基礎。