Intel TME和MKTME技術解析

市場需求

人們對透明全記憶體加密這個功能的需求主要來自對機密和敏感資料的保護。普通RAM裡面儲存的資料，在掉電之後，一般都以為是徹底消失了。但其實在一些複雜的離線攻擊下，這些資料仍然是能被恢複出來并導緻洩密；而持久性存儲器（即外存，包括磁盤、SSD、eMMC等）的資料更加容易洩露。這些裝置可能有硬體鎖機制的保護，但是使用者其實希望的是更細粒度的保護，比如per程序/容器/VM級的。

Intel制定了Intel架構下的記憶體加密技術規範，即TME架構，以及建構在這個架構之上的、能滿足更細粒度記憶體加密需求的MKTME。

TME架構

TME是Total Memory Encryption的縮寫。該架構定義并實作了透明全記憶體加密特性的最基本功能：使用由處理器内的RNG生成的單一的臨時密鑰對全部實體記憶體（包括NVRAM）以透明地方式進行加密。 所謂“臨時”指的是每次處理器啟動時都會通過RNG重新生成一把密鑰，這把密鑰被稱為平台密鑰。一旦開啟TME特性，TME exclusion區域以外的全部記憶體區域全都使用平台密鑰進行加解密。

為了防止平台密鑰的洩露，軟體或處理器接口都無法通路到這把平台密鑰。

下圖是TME架構在一個具有雙NUMA節點系統中的參考實作圖：

在系統啟動的早期階段，BIOS就會開啟該TME。一旦開啟了該特性，在外部記憶體總線上和DIMM中觀測到的一律都是加密後的資料。 能夠達到這種效果的原因是處在cache與DRAM/NVRAM控制器之間的AES-XTS加解密引擎對所有進出cache的資料一律要進行解密和加密處理。由于cache、寄存器以及更偏向處理器核一側的其他微架構層元件仍舊使用明文資料，是以TME架構對已有的軟體和I/O模型來說是完全透明的。

總體而言，TME架構具有以下特點：

• 架構和功能簡單直接：使用單一的平台密鑰對記憶體進行加密
• 一些更複雜的安全特性（比如SGX2和TDX）可以輕易地疊加在這個基礎架構之上
• 對軟體幾乎完全透明，相容性好
• 對性能的影響與工作負載強相關

TME的最大缺點是隻能使用一把平台密鑰來加密記憶體，不支援在系統裡劃分出多個基于加密密鑰建構的加密記憶體domain；但MKTME就支援使用多把密鑰，進而實作per程序/容器/VM粒度的加密記憶體domain。

MKTME

MKTME是Multi-Key Total Memory Encryption的縮寫。它在TME架構的基礎上，實作了以頁為粒度、支援使用多把密鑰對記憶體進行加密的功能，同時還允許由軟體設定AES-XTS加解密引擎所使用的密鑰。

下圖是将MKTME用在虛拟化場景中的一個示例圖：

在這個示例中：

• Hypervisor使用KeyID 0 (即TME定義的平台密鑰)來通路所有的加密記憶體
• VM1和VM2都可以使用KeyID 0來通路自己的加密記憶體
• VM1使用KeyID 1來通路自己的私有加密記憶體
• VM2使用KeyID 2來通路自己的私有加密記憶體
• VM1和VM2可以使用KeyID 3來通路兩個VM共享的加密記憶體

KeyID字段被包含在PTE中，且位于實體位址字段的高位，就像是實體位址字段的一部分（即通過減少一部分實體位址寬度來實作），同時被用在處理器内部的微架構層中（除了AES-XTS引擎），這個特性叫做實體位址位超賣（oversubscribing）。該特性使實體位址具有了别名，即具有相同實體位址的頁可以有不同的KeyID。

KeyID資訊是不會出現在處理器外部的（比如記憶體總線上）。實體位址位超賣不會影響cache和TLB的行為，因為KeyID僅被當做成實體位址的一部分來處理；但實體位址位超賣會影響大多數的頁表類型：Host普通IA頁表、EPT和IOMMU頁表。

• IA paging

  MKTME會影響Host側的IA paging（含每一級頁表），即在實體位址字段的高位中包含KeyID字段；CR3寄存器也受此影響，也包含了KeyID。

MKTME不會影響Guest中的IA paging，因為Guest中的IA paging用于産生GPA，而不是最終的HPA，是以設計設計上沒必要在Guest的IA paging中設定KeyID字段，即GPA中不包含KeyID，是以也無法為VM的應用再提供更細粒度的密碼學隔離。

• EPT paging

  MKTME會影響EPT paging（含每一級頁表），因為EPT用于将GPA映射到HPA，而HPA必須要包含KeyID。

• 其他實體位址

  其他的實體位址結構（如VMCS指針、實體位址位圖等）也都需要包含KeyID。

雖然前面的例子中Hypervisor使用的是KeyID 0，但Hypervisor具有特權，可以使用任意KeyID通路自己的加密記憶體，也能管理和設定每個VM所能使用的KeyID。

MKTME支援的密鑰數量總是固定的，而具體數量由特定的處理器實作來決定。軟體可以通過配置隻使用其中的部分密鑰，這組密鑰被稱為可用密鑰。軟體負責管理可用密鑰，并可以使用可用密鑰對任意一個記憶體頁進行加密。

在軟體不進行任何顯式配置的情況下，MKTME引擎預設使用TME的平台密鑰進行記憶體加密。MKTME也允許使用軟體提供的密鑰或處理器RNG生成的密鑰。 在虛拟化場景中，VMM或Hypervisor負責管理每個VM所使用的密鑰，并透明地對Guest OS實施加密保護（在這個場景中，可以将MKTME視為TME虛拟化技術）。

總而言之，MKTME希望在系統層面能夠建立多個獨立的加密記憶體domain。 這對使用者來說也更加安全。

安全威脅模型分析

TME和MKTME的安全性依賴于特權軟體（OS和VMM/Hypervisor），這點與傳統虛拟化技術的安全邊界完全一緻。 假設在攻擊者擁有特權的情況下，攻擊者能将所有實體頁的加密模式都改為非加密模式。事實上隻要攻擊者擁有特權，就已經能夠通路任意記憶體了，隻不過需要使用正确的KeyID來通路per程序/容器/VM執行個體的加密記憶體，比如在通路VM執行個體内的資料前需要在EPT PTE中找出正确的KeyID，然後建立一個使用該KeyID的PTE映射來通路該實體頁。

此外，TME和MKTME沒有對資料提供完整性保護，是以軟體使用錯誤的KeyID通路加密記憶體、或直接篡改加密記憶體中的内容都是可行的。

由于軟體和處理器接口無法通路到TME平台密鑰以及MKTME中由處理器硬體自生成的密鑰，是以密鑰本身是存儲安全的；但由軟體提供的MKTME密鑰可能會因調用者考慮不周而遭到洩露，這個難題需要軟體設計者自己來解決。

由于cache中的資料是明文的，是以TME和MKTME無法抵禦像L1TF這種利用處理器speculative execution側信道漏洞的攻擊方式來間接probe cache中的明文資料的這種攻擊方式。

綜上所述，由于特權軟體仍有足夠的權限來降低TME和MKTME的安全性，是以TME/MKTME技術目前還不屬于機密計算的範疇，即無法做到哪怕在被攻破的OS/VMM環境裡也能夠保護租戶機密資料的強度。 TME和MKTME防範的攻擊路徑是從惡意VM執行個體到Hypervisor。更具體來說，隻要攻擊者無法跨域安全域（指從guest ring0到host ring0）且在軟體采用了正确配置的情況下，TME和MKTME就能夠抵禦惡意VM執行個體對Host或其他VM執行個體的資料洩露攻擊；但前提是租戶必須信任CSP（即Hypervisor和host所能提供的安全性，同時CSP不會作惡）和Intel CPU。

目前Intel MKTME也在繼續進行疊代，相信很快就能看到能與AMD SEV中防止特權軟體修改VM執行個體記憶體加密模式的保護機制了。

Linux支援情況

在Icelake這一代不會在Linux kernel upstream中提供對MKTME的單獨支援了，需要等到Intel下一代處理器；但Icelake不單獨支援不意味着這個技術沒用。Icelake支援SGX2，而SGX2的MEE相較于SGX1就改用MKTME提供記憶體加密的能力，隻不過這個MKTME對系統軟體不可見。

目前Linux upstream對MKTME的支援僅僅提供了最最基本的CPU枚舉和PCONFIG的實作，之前提的一些patch也沒有合入upstream。

參考

• TME介紹
• Intel Architecture Memory Encryption Technologies Specification
• LWN: memory加密方案讨論
• [Runtime VM Protection By Intel MKTME]( https://schd.ws/hosted_files/lc32018/38/mktme_lc3_2018.pdf