市場需求
人們對透明全內存加密這個功能的需求主要來自對機密和敏感數據的保護。普通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的應用再提供更細粒度的密碼學隔離（即per VM應用級的KeyID）。
-
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。