一、前言
近日Positive Technologies研究團隊對英特爾的管理引擎（Intel Management Engine，Intel ME）11的內部構造深入分析研究之后，找到了在硬件初始化及主處理器啟動后禁用Intel ME的一種方法。在本文中，我們會介紹發現這個未公開模式的詳細過程，也會介紹這一模式與美國政府的高保證平臺（High Assurance Platform，HAP）之間的具體關系。
免責聲明：本文介紹的方法存在一定的風險，可能會損壞或損毀你的計算機。我們對用戶的任何實驗行為不承擔任何責任，也不保證整個過程能順利完成。如果有人了解相關風險后想繼續實驗，建議在SPI（Serial Peripheral Interface，串行外設接口）編程器的幫助下進行。
二、簡介
Intel ME是一項專有技術，由集成在平臺控制單元（Platform Controller Hub，PCH）中的一個微控制器以及一組內置的外部設備所組成。PCH承擔了處理器與外部設備之間的絕大部分通信，因此，Intel ME可以訪問計算機上的幾乎所有數據。如果攻擊者可以在Intel ME上執行第三方代碼，他就能完全控制整個平臺。世界各地的研究人員對Intel ME的內部構造越來越感興趣，其中一個原因在于這個子系統已經遷移到了新的硬件（x86）以及軟件（操作系統為修改版的MINIX）平臺上。在x86平臺上，研究者可以使用得心應手的二進制代碼分析工具。在此之前，對相關固件的分析非常困難，因為早期版本的ME使用了ARCompact微控制器，指令集完全不同。
不幸的是，之前我們無法分析Intel ME 11，因為其中的可執行模塊經過霍夫曼（Huffman）編碼的壓縮，使用了未知的壓縮表。盡管如此，我們的研究團隊（Dmitry Sklyarov、Mark Ermolov以及Maxim Goryachy三名成員）還是成功恢復了這些壓縮表，開發了一個工具來解壓鏡像。大家可以在GitHub上下載這個工具。
解壓可執行模塊之后，我們繼續研究Intel ME的內部軟件及硬件結構。我們的團隊一直在這方面開展研究，也累積了大量研究成果，這些成果將于未來逐步公開。本文也是分析Intel ME內部構造及禁用ME核心功能系列文章的第一篇文章。一直以來，研究人員致力于找到禁用該功能的具體方法，以減輕Intel ME中的任何零日漏洞可能帶來的數據泄露風險。
三、如何禁用ME
某些x86計算機用戶曾經問過這樣一個問題：如何禁用Intel ME？包括Positive Technologies專家在內的許多人已經多次提出過這個問題�；�于Intel ME的英特爾主動管理技術（Intel Active Management Technology，AMT）最近出現了一個嚴重漏洞（評分為9.8/10），隨著這個漏洞的披露，找到這個問題的答案也愈加緊迫。
令人失望的是，在現代計算機上，我們無法完全禁用ME。原因主要是因為這項技術負責初始化、管理電源以及啟動主處理器。另一個復雜原因在于，某些數據被集成在PCH芯片內部，而PCH正是現代主板上的南橋。某些愛好者嘗試在維持計算機可操作性的前提下，移除了ME鏡像中的所有“冗余”部分，實現對ME的禁用，這也是之前采用的主要方法。但這種方法沒有那么簡單，因為如果內置的PCH代碼沒有在閃存中找到ME模塊，或者檢測到相關模塊處于損壞狀態，那么系統將無法啟動。
經過多年的研發，me_cleaner項目已經開發了一個實用工具，可以刪掉ME鏡像中的大部分組件，只保留對主系統來說至關重要的組件。但這樣處理后，即使系統成功啟動，留給我們的時間也非常短，大約30秒之后系統就可能會自動關機。原因在于，一旦出現故障，ME就會進入恢復模式（Recovery Mode），在這個模式下，系統只能運行一段時間。這樣一來，“瘦身”過程就會變得非常復雜。比如，在早期版本的Intel ME中，我們可以將鏡像大小縮小到90KB，但Intel ME 11的鏡像只能縮小到650KB。

四、隱藏在QResource中的秘密
Intel允許主板廠商設置少量ME參數。Intel為硬件廠商提供了特殊的軟件來實現這一點，這些軟件包括用于配置ME參數的閃存鏡像工具（Flash Image Tool，FIT），以及通過內置的SPI控制器來直接對閃存進行編程的閃存編程工具（Flash Programming Tool，FPT）。這些程序并沒有提供給最終用戶，但我們很容易就能在網上找到這些工具的下載地址。

我們可以從這些工具中提取出大量XML文件（詳細過程請點擊此鏈接）。這些文件包含許多有趣的信息，包括ME固件的結構、PCH strap的描述以及集成在PCH芯片中的各種子系統的特殊配置信息。其中名為“reserve_hap”的某個字段引起了我們的注意，因為這個字段后緊跟著一行注釋：“啟用高保證平臺（HAP）”。

使用Google搜索后，我們很快就找到了一些信息。根據搜索結果，該字段與美國國家安全局（NSA）的可信平臺計劃（trusted platform program）有關。關于這個計劃，大家可以訪問此鏈接了解詳細信息。首先，我們第一反應是設置一下這個比特位，看設置完畢后會發生什么情況。只要掌握SPI編程器或者可以訪問閃存描述符（Flash Descriptor），我們就可以設置這個比特（許多主板通常沒有正確設置對閃存區域的訪問權限）。

平臺加載后，MEInfo工具報告了一個非常奇怪的狀態：“Alt Disable Mode.（Alt禁用模式）”。經過快速檢查，我們發現ME沒有響應命令，也沒有對操作系統發出的請求做出反應。我們決定找出系統進入這個模式的原因，以及當前這種情況的具體意義。當時，我們已經分析了BUP模塊的主要部分，這個模塊用于平臺的初始化，也用于設置MEInfo所顯示的狀態。為了了解BUP的工作機制，我們需要詳細介紹一下Intel ME軟件環境的具體信息。
五、Intel ME 11架構概覽
從PCH 100系列開始，Intel完全重新設計了PCH芯片。嵌入式微控制器的架構由ARC的ARCompact切換到x86架構。Intel選擇Minute IA（MIA）32位微控制器作為基礎單元，該微控制器在Intel Edison微機以及SoC Quark上使用，結合使用了Intel 486微處理器以及奔騰處理器的一組指令集（ISA）。然而，對于PCH來說，Intel使用22納米半導體技術制造了核心組件，使得微控制器具備更高的能效。在新的PCH中有三個這樣的核心組件：管理引擎（ME）、集成傳感器中心（Integrated Sensors Hub，ISH）以及創新引擎（Innovation Engine，IE）。后兩者可根據PCH模型以及目標平臺啟用或者禁用，而ME核心始終處于啟用狀態。

這種大范圍的修改同樣涉及到ME軟件的修改。具體說來，MINIX被選擇作為基礎操作系統（之前使用的是ThreadX RTOS）。現在的ME固件包含全功能版的操作系統，包括進程、線程、內存管理、硬件總線驅動、文件系統以及其他許多組件。ME中也集成了一個硬件加密處理器，支持SHA256、AES、RSA以及HMAC。用戶進程可以通過本地描述符表（local descriptor table ，LDT）來訪問硬件。進程的地址空間由LDT進行管理，該空間只是內核的全局地址空間的一部分，內核全局地址空間也由本地描述符來指定。因此，與Windows或Linux系統不同的是，內核不需要在不同進程的內存之間進行切換（修改頁表目錄）。
了解Intel ME軟件的背景知識后，現在我們可以分析操作系統以及模塊的具體加載過程。
六、Intel ME加載過程的各個階段
整個加載過程從ROM程序開始，ROM程序位于內置的PCH只讀存儲區中。不幸的是，普通用戶無法掌握讀取或重寫這部分存儲區的方法。然而，我們可以在網上找到ME固件的預發行版，這個版本包含ROMB（ROM BYPASS）組件，我們假定這個組件與ROM的功能有所重復。因此，檢查這個固件后，我們就可能重現初始化程序的基本功能。
通過檢查ROMB，我們可以確定ROM執行一系列操作的目的，這些操作包括初始化硬件（比如，初始化SPI控制器）、驗證FTPR頭部的數字簽名、加載閃存中的RBE模塊。然后，RBE會驗證KERNEL、SYSLIB以及BUP模塊的校驗和，并將控制權交給內核入口點。
需要注意的是，ROM、RBE以及KERNEL的執行位于MIA內核的0權限（ring-0）級別下。

內核創建的第一個進程是BUP，這個進程運行在ring-3級別的自身地址空間中。內核本身并不會啟動其他任何進程，這些動作由BUP來完成，還有另一個獨立的模塊（LOADMGR），后面我們會專門討論。BUP（BringUP平臺）的目的是初始化平臺（包括處理器）的整個硬件環境，執行主電源管理功能（比如，當按下電源鍵時啟動平臺），并且啟動所有其他ME進程。因此，可以肯定的是，如果缺少有效的ME固件，PCH 100以及更高版本系列物理上就無法從啟動。首先，BUP會初始化電源管理控制器（PMC）以及ICC控制器。其次，BUP會根據某些字符串來啟動某些進程，其中某些字符串硬編碼在固件中（如SYNCMAN、PM、VFS），其他字符串包含在InitScript中（InitScript類似于autorun，保存在FTPR卷標頭中，經過數字簽名）。

因此，BUP會讀取InitScript，啟動符合ME啟動類型的所有IBL進程。


如果某個進程無法啟動，BUP就不會啟動系統。如圖9所示，LOADMGR是列表中的最后一個IBL進程。該進程會啟動剩余的進程，但與BUP不同的是，如果模塊啟動過程中出現錯誤，LOADMGR會繼續執行下一個模塊。
這意味著給Intel ME“瘦身”的第一種方法是刪除InitScript中沒有IBL標志的所有模塊，這樣就能顯著減少固件的大小。但我們最初的任務是找到HAP模式下的ME出現了什么狀況。為了找到問題的答案，我們可以看一下BUP軟件模型。

七、BringUP
如果你仔細研究BUP模塊的工作方式，你會發現BUP中實現了一個經典的有限狀態機。執行過程從功能上分為兩個部分：初始化階段（有限狀態機）以及在系統初始化后根據其他進程的請求來執行服務。根據平臺以及SKU（TXE、CSME、SPS、消費者以及企業）的不同，初始化階段的數量也會有所不同，但對于所有版本來說，主要的階段都是相同的。7.1 階段1
初始化階段會創建sfs內部診斷文件系統（SUSRAM FS，位于非易失性存儲區中的一個文件系統），讀取配置信息，最關鍵的是，會向PMC查詢哪個動作觸發了啟動過程：是平臺插電、整個平臺的重啟、ME重啟還是從睡眠中喚醒。這個階段稱之為啟動流確定階段。有限狀態機初始化的后續階段需要依賴這一階段。此外，這一階段還支持多種模式：普通模式以及一組服務模式，后一個模式中，主ME功能處于禁用狀態（如HAP、HMRFPO、TEMPDISABLE、RECOVERY、SAFEMODE、FWUPDATE以及FDOVERRIDE功能）。
7.2 階段2
這個階段會初始化ICC控制器，加載ICC配置文件（負責主要消費者的時鐘頻率）。同時，這個階段會初始化Boot Guard，開啟處理器啟動確認的輪詢過程。
7.3 階段3
BUP等待來自PMC的一則信息，以確認主處理器已啟動。隨后，BUP啟動電源事件的PMC異步輪詢過程（平臺的重啟或關閉），然后進入下一階段。如果這類事件發生，那么BUP就會執行初始化階段所請求的動作。
7.4 階段4
這個階段會初始化內部硬件。與此同時，BUP啟動heci輪詢（heci是個特殊設備，用來接收來自BIOS或操作系統的命令），查詢BIOS中的DID（DRAM Init Done，DRAM初始化完成）信息。這個消息可以讓ME確定主BIOS是否已完成RAM的初始化并為ME保留一個特殊的區域（UMA），之后會進入下一個階段。
7.5 階段5
一旦收到DID消息，根據具體的模式不同（這個模式由多種因素決定），BUP會（以正常模式）啟動InitScript中的IBL進程，或者會在循環中掛起，只有收到來自PMC的消息（例如收到重啟或關閉系統的請求）才會退出循環。
正是在這個階段，我們找到了HAP處理過程。在這個模式中，BUP會掛起，不會執行InitScript。這意味著正常模式中的后續動作與HAP沒有關系，因此也不需要去考慮。我們需要重點關注的是，在HAP模式下，BUP會初始化整個平臺（ICC、Boot Gurad），但不會啟動主ME進程。



八、設置HAP比特
根據前面的分析，我們可以找到第二種方法來禁用Intel ME：
1、設置HAP比特。
2、在FTPR的CPD區中，刪除或破壞除BUP啟動需要用到的模塊之外的其他所有模塊，BUP啟動需要用到如下模塊：
RBE
KERNEL
SYSLIB
dBUP
3、修復CPD頭部的校驗值（可訪問此鏈接了解ME固件結構的詳細信息）。
那么，我們如何設置HAP比特？我們可以使用FIT配置文件，確定鏡像中該比特的具體位置，但還有另一種更為簡單的方法。在FIT的ME內核區中，我們可以找到一個保留參數。這個比特可以啟動HAP模式。

九、HAP以及Boot Guard
此外，我們還在BUP中找到某些代碼，當HAP模式處于啟用狀態時，這些代碼會在Boot Guard策略中設置一個額外的比特。不幸的是，我們還沒有找到這個比特所控制的具體對象。

十、me_cleaner中對ME 11的支持
當我們在準備這篇文章時，me_cleaner開發者更新了他們的程序。現在，這個程序也可以刪除鏡像中除RBE、KERNEL、SYSLIB以及BUP之外的所有模塊，但沒有設置HAP比特，這樣就會迫使ME進入TemporaryDisable（臨時禁用）模式。我們很好奇這種做法會導致什么情況出現。
我們發現刪除分區以及ME文件系統后，會導致cfgrules文件讀取過程中出現錯誤。這個文件包含許多不同的系統設置。正如我們猜測的那樣，這些系統設置中包含一個名為“bupnottemporarydisable”的標志。如果沒有設置這個標志，整個子系統就會切換到TemporaryDisable模式，此外，由于這個標志為初始化為0的全局變量，因此讀取錯誤會被當成已斷開的配置請求錯誤。
此外，我們還檢查了服務器版以及移動版的ME固件（SPS 4.x以及TXE 3.x）。在服務器版本中，這個標志總是設為1；在移動版本中，這個標志會被忽略。這意味著這種方法在服務器版以及移動版（Apollo Lake）的ME中無法奏效。

十一、尾聲
在本文中，我們找到了一個未公開的PCH strap，可以切換到一種特殊的模式，在早期階段就能禁用Intel ME的主要功能。之所以能得出這個結論，主要依據有三點：
1、依據對Intel ME固件的二進制分析過程，如前文所述。
2、如果我們移除某些關鍵的ME模塊并啟動HAP模式，Intel ME并不會崩潰。這足以證明HAP在早期階段就禁用了ME。
3、我們非�？隙↖ntel ME無法退出這個模式，因為我們沒有在RBE、KERNEL以及SYSLIB模塊中找到能夠執行此操作的相關代碼。
同樣，我們可以確定的是，集成到PCH中的ROM實際上與ROMB相同，ROMB中也沒有包含退出HAP模式的任何代碼。
因此，HAP可以防護除RBE、KERNEL、SYSLIB、ROM以及BUP模塊之外的所有模塊中可能存在的漏洞。然而，不幸的是這個模式無法防止攻擊者利用早期階段中存在的錯誤。
Intel表示他們已得知我們的研究細節。從他們的回應中，證實了我們對HAP程序未公開模式的猜想。在Intel的許可下，我們摘抄了部分回應內容，如下所示：
“致Mark/Maxim：
為了響應具有特殊要求的客戶請求，我們有時候會修改或禁用某些功能。在這種情況下，我們會根據設備制造商的要求進行修改，以響應客戶對美國政府的“高保證平臺”計劃的支持。這些修改的驗證周期較為有限，并不是官方支持的配置。”
我們可以肯定的是，這種機制旨在滿足政府機構的典型需求，以減少側信道數據泄露的風險。但主要的問題仍然沒有得到解決：那就是HAP如何影響Boot Guard？由于HAP是一項封閉性技術，我們無法回答這個問題，但我們衷心的希望在不久的未來這個問題能夠得到解答。