一、前言
近日Positive Technologies研究團(tuán)隊(duì)對英特爾的管理引擎（Intel Management Engine，Intel ME）11的內(nèi)部構(gòu)造深入分析研究之后，找到了在硬件初始化及主處理器啟動后禁用Intel ME的一種方法。在本文中，我們會介紹發(fā)現(xiàn)這個未公開模式的詳細(xì)過程，也會介紹這一模式與美國政府的高保證平臺（High Assurance Platform，HAP）之間的具體關(guān)系。
免責(zé)聲明：本文介紹的方法存在一定的風(fēng)險，可能會損壞或損毀你的計(jì)算機(jī)。我們對用戶的任何實(shí)驗(yàn)行為不承擔(dān)任何責(zé)任，也不保證整個過程能順利完成。如果有人了解相關(guān)風(fēng)險后想繼續(xù)實(shí)驗(yàn)，建議在SPI（Serial Peripheral Interface，串行外設(shè)接口）編程器的幫助下進(jìn)行。
二、簡介
Intel ME是一項(xiàng)專有技術(shù)，由集成在平臺控制單元（Platform Controller Hub，PCH）中的一個微控制器以及一組內(nèi)置的外部設(shè)備所組成。PCH承擔(dān)了處理器與外部設(shè)備之間的絕大部分通信，因此，Intel ME可以訪問計(jì)算機(jī)上的幾乎所有數(shù)據(jù)。如果攻擊者可以在Intel ME上執(zhí)行第三方代碼，他就能完全控制整個平臺。世界各地的研究人員對Intel ME的內(nèi)部構(gòu)造越來越感興趣，其中一個原因在于這個子系統(tǒng)已經(jīng)遷移到了新的硬件（x86）以及軟件（操作系統(tǒng)為修改版的MINIX）平臺上。在x86平臺上，研究者可以使用得心應(yīng)手的二進(jìn)制代碼分析工具。在此之前，對相關(guān)固件的分析非常困難，因?yàn)樵缙诎姹镜腗E使用了ARCompact微控制器，指令集完全不同。
不幸的是，之前我們無法分析Intel ME 11，因?yàn)槠渲械目蓤?zhí)行模塊經(jīng)過霍夫曼（Huffman）編碼的壓縮，使用了未知的壓縮表。盡管如此，我們的研究團(tuán)隊(duì)（Dmitry Sklyarov、Mark Ermolov以及Maxim Goryachy三名成員）還是成功恢復(fù)了這些壓縮表，開發(fā)了一個工具來解壓鏡像。大家可以在GitHub上下載這個工具。
解壓可執(zhí)行模塊之后，我們繼續(xù)研究Intel ME的內(nèi)部軟件及硬件結(jié)構(gòu)。我們的團(tuán)隊(duì)一直在這方面開展研究，也累積了大量研究成果，這些成果將于未來逐步公開。本文也是分析Intel ME內(nèi)部構(gòu)造及禁用ME核心功能系列文章的第一篇文章。一直以來，研究人員致力于找到禁用該功能的具體方法，以減輕Intel ME中的任何零日漏洞可能帶來的數(shù)據(jù)泄露風(fēng)險。
三、如何禁用ME
某些x86計(jì)算機(jī)用戶曾經(jīng)問過這樣一個問題：如何禁用Intel ME？包括Positive Technologies專家在內(nèi)的許多人已經(jīng)多次提出過這個問題。基于Intel ME的英特爾主動管理技術(shù)（Intel Active Management Technology，AMT）最近出現(xiàn)了一個嚴(yán)重漏洞（評分為9.8/10），隨著這個漏洞的披露，找到這個問題的答案也愈加緊迫。
令人失望的是，在現(xiàn)代計(jì)算機(jī)上，我們無法完全禁用ME。原因主要是因?yàn)檫@項(xiàng)技術(shù)負(fù)責(zé)初始化、管理電源以及啟動主處理器。另一個復(fù)雜原因在于，某些數(shù)據(jù)被集成在PCH芯片內(nèi)部，而PCH正是現(xiàn)代主板上的南橋。某些愛好者嘗試在維持計(jì)算機(jī)可操作性的前提下，移除了ME鏡像中的所有“冗余”部分，實(shí)現(xiàn)對ME的禁用，這也是之前采用的主要方法。但這種方法沒有那么簡單，因?yàn)槿绻麅?nèi)置的PCH代碼沒有在閃存中找到ME模塊，或者檢測到相關(guān)模塊處于損壞狀態(tài)，那么系統(tǒng)將無法啟動。
經(jīng)過多年的研發(fā)，me_cleaner項(xiàng)目已經(jīng)開發(fā)了一個實(shí)用工具，可以刪掉ME鏡像中的大部分組件，只保留對主系統(tǒng)來說至關(guān)重要的組件。但這樣處理后，即使系統(tǒng)成功啟動，留給我們的時間也非常短，大約30秒之后系統(tǒng)就可能會自動關(guān)機(jī)。原因在于，一旦出現(xiàn)故障，ME就會進(jìn)入恢復(fù)模式（Recovery Mode），在這個模式下，系統(tǒng)只能運(yùn)行一段時間。這樣一來，“瘦身”過程就會變得非常復(fù)雜。比如，在早期版本的Intel ME中，我們可以將鏡像大小縮小到90KB，但I(xiàn)ntel ME 11的鏡像只能縮小到650KB。
四、隱藏在QResource中的秘密
Intel允許主板廠商設(shè)置少量ME參數(shù)。Intel為硬件廠商提供了特殊的軟件來實(shí)現(xiàn)這一點(diǎn)，這些軟件包括用于配置ME參數(shù)的閃存鏡像工具（Flash Image Tool，F(xiàn)IT），以及通過內(nèi)置的SPI控制器來直接對閃存進(jìn)行編程的閃存編程工具（Flash Programming Tool，F(xiàn)PT）。這些程序并沒有提供給最終用戶，但我們很容易就能在網(wǎng)上找到這些工具的下載地址。
我們可以從這些工具中提取出大量XML文件（詳細(xì)過程請點(diǎn)擊此鏈接）。這些文件包含許多有趣的信息，包括ME固件的結(jié)構(gòu)、PCH strap的描述以及集成在PCH芯片中的各種子系統(tǒng)的特殊配置信息。其中名為“reserve_hap”的某個字段引起了我們的注意，因?yàn)檫@個字段后緊跟著一行注釋：“啟用高保證平臺（HAP）”。
使用Google搜索后，我們很快就找到了一些信息。根據(jù)搜索結(jié)果，該字段與美國國家安全局（NSA）的可信平臺計(jì)劃（trusted platform program）有關(guān)。關(guān)于這個計(jì)劃，大家可以訪問此鏈接了解詳細(xì)信息。首先，我們第一反應(yīng)是設(shè)置一下這個比特位，看設(shè)置完畢后會發(fā)生什么情況。只要掌握SPI編程器或者可以訪問閃存描述符（Flash Descriptor），我們就可以設(shè)置這個比特（許多主板通常沒有正確設(shè)置對閃存區(qū)域的訪問權(quán)限）。
平臺加載后，MEInfo工具報告了一個非常奇怪的狀態(tài)：“Alt Disable Mode.（Alt禁用模式）”。經(jīng)過快速檢查，我們發(fā)現(xiàn)ME沒有響應(yīng)命令，也沒有對操作系統(tǒng)發(fā)出的請求做出反應(yīng)。我們決定找出系統(tǒng)進(jìn)入這個模式的原因，以及當(dāng)前這種情況的具體意義。當(dāng)時，我們已經(jīng)分析了BUP模塊的主要部分，這個模塊用于平臺的初始化，也用于設(shè)置MEInfo所顯示的狀態(tài)。為了了解BUP的工作機(jī)制，我們需要詳細(xì)介紹一下Intel ME軟件環(huán)境的具體信息。
五、Intel ME 11架構(gòu)概覽
從PCH 100系列開始，Intel完全重新設(shè)計(jì)了PCH芯片。嵌入式微控制器的架構(gòu)由ARC的ARCompact切換到x86架構(gòu)。Intel選擇Minute IA（MIA）32位微控制器作為基礎(chǔ)單元，該微控制器在Intel Edison微機(jī)以及SoC Quark上使用，結(jié)合使用了Intel 486微處理器以及奔騰處理器的一組指令集（ISA）。然而，對于PCH來說，Intel使用22納米半導(dǎo)體技術(shù)制造了核心組件，使得微控制器具備更高的能效。在新的PCH中有三個這樣的核心組件：管理引擎（ME）、集成傳感器中心（Integrated Sensors Hub，ISH）以及創(chuàng)新引擎（Innovation Engine，IE）。后兩者可根據(jù)PCH模型以及目標(biāo)平臺啟用或者禁用，而ME核心始終處于啟用狀態(tài)。
這種大范圍的修改同樣涉及到ME軟件的修改。具體說來，MINIX被選擇作為基礎(chǔ)操作系統(tǒng)（之前使用的是ThreadX RTOS）。現(xiàn)在的ME固件包含全功能版的操作系統(tǒng)，包括進(jìn)程、線程、內(nèi)存管理、硬件總線驅(qū)動、文件系統(tǒng)以及其他許多組件。ME中也集成了一個硬件加密處理器，支持SHA256、AES、RSA以及HMAC。用戶進(jìn)程可以通過本地描述符表（local descriptor table ，LDT）來訪問硬件。進(jìn)程的地址空間由LDT進(jìn)行管理，該空間只是內(nèi)核的全局地址空間的一部分，內(nèi)核全局地址空間也由本地描述符來指定。因此，與Windows或Linux系統(tǒng)不同的是，內(nèi)核不需要在不同進(jìn)程的內(nèi)存之間進(jìn)行切換（修改頁表目錄）。
了解Intel ME軟件的背景知識后，現(xiàn)在我們可以分析操作系統(tǒng)以及模塊的具體加載過程。
六、Intel ME加載過程的各個階段
整個加載過程從ROM程序開始，ROM程序位于內(nèi)置的PCH只讀存儲區(qū)中。不幸的是，普通用戶無法掌握讀取或重寫這部分存儲區(qū)的方法。然而，我們可以在網(wǎng)上找到ME固件的預(yù)發(fā)行版，這個版本包含ROMB（ROM BYPASS）組件，我們假定這個組件與ROM的功能有所重復(fù)。因此，檢查這個固件后，我們就可能重現(xiàn)初始化程序的基本功能。
通過檢查ROMB，我們可以確定ROM執(zhí)行一系列操作的目的，這些操作包括初始化硬件（比如，初始化SPI控制器）、驗(yàn)證FTPR頭部的數(shù)字簽名、加載閃存中的RBE模塊。然后，RBE會驗(yàn)證KERNEL、SYSLIB以及BUP模塊的校驗(yàn)和，并將控制權(quán)交給內(nèi)核入口點(diǎn)。
需要注意的是，ROM、RBE以及KERNEL的執(zhí)行位于MIA內(nèi)核的0權(quán)限（ring-0）級別下。
內(nèi)核創(chuàng)建的第一個進(jìn)程是BUP，這個進(jìn)程運(yùn)行在ring-3級別的自身地址空間中。內(nèi)核本身并不會啟動其他任何進(jìn)程，這些動作由BUP來完成，還有另一個獨(dú)立的模塊（LOADMGR），后面我們會專門討論。BUP（BringUP平臺）的目的是初始化平臺（包括處理器）的整個硬件環(huán)境，執(zhí)行主電源管理功能（比如，當(dāng)按下電源鍵時啟動平臺），并且啟動所有其他ME進(jìn)程。因此，可以肯定的是，如果缺少有效的ME固件，PCH 100以及更高版本系列物理上就無法從啟動。首先，BUP會初始化電源管理控制器（PMC）以及ICC控制器。其次，BUP會根據(jù)某些字符串來啟動某些進(jìn)程，其中某些字符串硬編碼在固件中（如SYNCMAN、PM、VFS），其他字符串包含在InitScript中（InitScript類似于autorun，保存在FTPR卷標(biāo)頭中，經(jīng)過數(shù)字簽名）。
因此，BUP會讀取InitScript，啟動符合ME啟動類型的所有IBL進(jìn)程。
如果某個進(jìn)程無法啟動，BUP就不會啟動系統(tǒng)。如圖9所示，LOADMGR是列表中的最后一個IBL進(jìn)程。該進(jìn)程會啟動剩余的進(jìn)程，但與BUP不同的是，如果模塊啟動過程中出現(xiàn)錯誤，LOADMGR會繼續(xù)執(zhí)行下一個模塊。
這意味著給Intel ME“瘦身”的第一種方法是刪除InitScript中沒有IBL標(biāo)志的所有模塊，這樣就能顯著減少固件的大小。但我們最初的任務(wù)是找到HAP模式下的ME出現(xiàn)了什么狀況。為了找到問題的答案，我們可以看一下BUP軟件模型。
七、BringUP
如果你仔細(xì)研究BUP模塊的工作方式，你會發(fā)現(xiàn)BUP中實(shí)現(xiàn)了一個經(jīng)典的有限狀態(tài)機(jī)。執(zhí)行過程從功能上分為兩個部分：初始化階段（有限狀態(tài)機(jī)）以及在系統(tǒng)初始化后根據(jù)其他進(jìn)程的請求來執(zhí)行服務(wù)。根據(jù)平臺以及SKU（TXE、CSME、SPS、消費(fèi)者以及企業(yè)）的不同，初始化階段的數(shù)量也會有所不同，但對于所有版本來說，主要的階段都是相同的。7.1 階段1
初始化階段會創(chuàng)建sfs內(nèi)部診斷文件系統(tǒng)（SUSRAM FS，位于非易失性存儲區(qū)中的一個文件系統(tǒng)），讀取配置信息，最關(guān)鍵的是，會向PMC查詢哪個動作觸發(fā)了啟動過程：是平臺插電、整個平臺的重啟、ME重啟還是從睡眠中喚醒。這個階段稱之為啟動流確定階段。有限狀態(tài)機(jī)初始化的后續(xù)階段需要依賴這一階段。此外，這一階段還支持多種模式：普通模式以及一組服務(wù)模式，后一個模式中，主ME功能處于禁用狀態(tài)（如HAP、HMRFPO、TEMPDISABLE、RECOVERY、SAFEMODE、FWUPDATE以及FDOVERRIDE功能）。
7.2 階段2
這個階段會初始化ICC控制器，加載ICC配置文件（負(fù)責(zé)主要消費(fèi)者的時鐘頻率）。同時，這個階段會初始化Boot Guard，開啟處理器啟動確認(rèn)的輪詢過程。
7.3 階段3
BUP等待來自PMC的一則信息，以確認(rèn)主處理器已啟動。隨后，BUP啟動電源事件的PMC異步輪詢過程（平臺的重啟或關(guān)閉），然后進(jìn)入下一階段。如果這類事件發(fā)生，那么BUP就會執(zhí)行初始化階段所請求的動作。
7.4 階段4
這個階段會初始化內(nèi)部硬件。與此同時，BUP啟動heci輪詢（heci是個特殊設(shè)備，用來接收來自BIOS或操作系統(tǒng)的命令），查詢BIOS中的DID（DRAM Init Done，DRAM初始化完成）信息。這個消息可以讓ME確定主BIOS是否已完成RAM的初始化并為ME保留一個特殊的區(qū)域（UMA），之后會進(jìn)入下一個階段。
7.5 階段5
一旦收到DID消息，根據(jù)具體的模式不同（這個模式由多種因素決定），BUP會（以正常模式）啟動InitScript中的IBL進(jìn)程，或者會在循環(huán)中掛起，只有收到來自PMC的消息（例如收到重啟或關(guān)閉系統(tǒng)的請求）才會退出循環(huán)。
正是在這個階段，我們找到了HAP處理過程。在這個模式中，BUP會掛起，不會執(zhí)行InitScript。這意味著正常模式中的后續(xù)動作與HAP沒有關(guān)系，因此也不需要去考慮。我們需要重點(diǎn)關(guān)注的是，在HAP模式下，BUP會初始化整個平臺（ICC、Boot Gurad），但不會啟動主ME進(jìn)程。
八、設(shè)置HAP比特
根據(jù)前面的分析，我們可以找到第二種方法來禁用Intel ME：
1、設(shè)置HAP比特。
2、在FTPR的CPD區(qū)中，刪除或破壞除BUP啟動需要用到的模塊之外的其他所有模塊，BUP啟動需要用到如下模塊：
RBE
KERNEL
SYSLIB
dBUP
3、修復(fù)CPD頭部的校驗(yàn)值（可訪問此鏈接了解ME固件結(jié)構(gòu)的詳細(xì)信息）。
那么，我們?nèi)绾卧O(shè)置HAP比特？我們可以使用FIT配置文件，確定鏡像中該比特的具體位置，但還有另一種更為簡單的方法。在FIT的ME內(nèi)核區(qū)中，我們可以找到一個保留參數(shù)。這個比特可以啟動HAP模式。
九、HAP以及Boot Guard
此外，我們還在BUP中找到某些代碼，當(dāng)HAP模式處于啟用狀態(tài)時，這些代碼會在Boot Guard策略中設(shè)置一個額外的比特。不幸的是，我們還沒有找到這個比特所控制的具體對象。
十、me_cleaner中對ME 11的支持
當(dāng)我們在準(zhǔn)備這篇文章時，me_cleaner開發(fā)者更新了他們的程序。現(xiàn)在，這個程序也可以刪除鏡像中除RBE、KERNEL、SYSLIB以及BUP之外的所有模塊，但沒有設(shè)置HAP比特，這樣就會迫使ME進(jìn)入TemporaryDisable（臨時禁用）模式。我們很好奇這種做法會導(dǎo)致什么情況出現(xiàn)。
我們發(fā)現(xiàn)刪除分區(qū)以及ME文件系統(tǒng)后，會導(dǎo)致cfgrules文件讀取過程中出現(xiàn)錯誤。這個文件包含許多不同的系統(tǒng)設(shè)置。正如我們猜測的那樣，這些系統(tǒng)設(shè)置中包含一個名為“bupnottemporarydisable”的標(biāo)志。如果沒有設(shè)置這個標(biāo)志，整個子系統(tǒng)就會切換到TemporaryDisable模式，此外，由于這個標(biāo)志為初始化為0的全局變量，因此讀取錯誤會被當(dāng)成已斷開的配置請求錯誤。
此外，我們還檢查了服務(wù)器版以及移動版的ME固件（SPS 4.x以及TXE 3.x）。在服務(wù)器版本中，這個標(biāo)志總是設(shè)為1；在移動版本中，這個標(biāo)志會被忽略。這意味著這種方法在服務(wù)器版以及移動版（Apollo Lake）的ME中無法奏效。
十一、尾聲
在本文中，我們找到了一個未公開的PCH strap，可以切換到一種特殊的模式，在早期階段就能禁用Intel ME的主要功能。之所以能得出這個結(jié)論，主要依據(jù)有三點(diǎn)：
1、依據(jù)對Intel ME固件的二進(jìn)制分析過程，如前文所述。
2、如果我們移除某些關(guān)鍵的ME模塊并啟動HAP模式，Intel ME并不會崩潰。這足以證明HAP在早期階段就禁用了ME。
3、我們非常肯定Intel ME無法退出這個模式，因?yàn)槲覀儧]有在RBE、KERNEL以及SYSLIB模塊中找到能夠執(zhí)行此操作的相關(guān)代碼。
同樣，我們可以確定的是，集成到PCH中的ROM實(shí)際上與ROMB相同，ROMB中也沒有包含退出HAP模式的任何代碼。
因此，HAP可以防護(hù)除RBE、KERNEL、SYSLIB、ROM以及BUP模塊之外的所有模塊中可能存在的漏洞。然而，不幸的是這個模式無法防止攻擊者利用早期階段中存在的錯誤。
Intel表示他們已得知我們的研究細(xì)節(jié)。從他們的回應(yīng)中，證實(shí)了我們對HAP程序未公開模式的猜想。在Intel的許可下，我們摘抄了部分回應(yīng)內(nèi)容，如下所示：
“致Mark/Maxim：
為了響應(yīng)具有特殊要求的客戶請求，我們有時候會修改或禁用某些功能。在這種情況下，我們會根據(jù)設(shè)備制造商的要求進(jìn)行修改，以響應(yīng)客戶對美國政府的“高保證平臺”計(jì)劃的支持。這些修改的驗(yàn)證周期較為有限，并不是官方支持的配置。”
我們可以肯定的是，這種機(jī)制旨在滿足政府機(jī)構(gòu)的典型需求，以減少側(cè)信道數(shù)據(jù)泄露的風(fēng)險。但主要的問題仍然沒有得到解決：那就是HAP如何影響B(tài)oot Guard？由于HAP是一項(xiàng)封閉性技術(shù)，我們無法回答這個問題，但我們衷心的希望在不久的未來這個問題能夠得到解答。
| 
