Notes about Intel TME and MKTME technology
本文将记录Intel的TME(Total Memory Encryption)和MKTME(Multi-Key Total Memory Encryption)技术。
Overview
Total Memory Encryption (TME) is a x86 instruction set extension proposed by Intel for a full physical memory encryption for DRAM and NVRAM with a single ephemeral key. TME can be further extended with the Multi-Key Total Memory Encryption (MKTME) extension which builds on TME and adds support multiple encryption keys.
TME
普通RAM里面储存的数据，在掉电之后，一般都以为是彻底消失了。但在一些复杂的离线攻击下，这些数据仍然是能被恢复出来并导致泄密。TME可以对抗这种攻击。
Total Memory Encryption (TME) – as name would imply is a capability to encrypt entirety of physical memory of a system. This capability is typically enabled in very early stages of boot process with small change to BIOS and once configured and locked will encrypt all the data on external memory buses of an SOC using NIST standard AES-XTS algorithm with 128-bit keys. The encryption key used for TME uses hardware random number generator implemented in Intel SOC and the keys are not accessible by software or using external interfaces to Intel SOC. TME capability is intended to provide protections of AES-XTS to external memory buses and DIMMs. The architecture is flexible and will support additional memory protections schemes in future. This capability when enabled is intended to support (unmodified) existing system and application software. Overall performance impact of this capability is likely to be relatively small and is highly dependent on workload.
Inside the chip itself (e.g., registers and caches) the data remains in plain text. This is done in order to maintain compatibility with all existing software and I/O models. An AES-XTS encryption engine is physically located directly on the data paths to external memory buses ensuring all data entering and leaving the chip is encrypted. Note that there is one exception for a specially defined exclusion range.
TME的最大缺点是只能使用一把平台密钥来加密内存，不支持在系统里划分出多个基于加密密钥构建的加密内存domain；但MKTME就支持使用多把密钥，进而实现per进程/容器/VM粒度的加密内存domain。
MKTME
Multi-Key Total Memory Encryption (MKTME) builds on TME and adds support for multiple encryption keys. The SOC implementation will support a fixed number of encryption keys, and software can configure SOC to use a subset of available keys. Software manages the use of keys and can use each of the available key for encrypting any page of the memory. Thus, MKTME allows page granular encryption of memory. By default MKTME uses TME encryption key unless explicitly specified by software. In addition to supporting CPU generated ephemeral key (not accessible by software or using external interfaces to SOC), MKTME also supports software provided keys. Software provided keys are particularly useful when used with non-volatile memory or when combined with attestation mechanisms and/or used with key provisioning services. In virtualization scenario, we anticipate VMM or hypervisor to manage use of keys to transparently support legacy operating systems without any changes. An OS may be enabled to take additional advantage of MKTME capability both in native or virtualized environment. When properly enabled, MKTME is available to each guest OS in virtualized environment, and guest OS can take advantage of MKTME in same was as native OS.
MKTME是在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中，且位于物理地址字段的高位，就像是物理地址字段的一部分（即通过减少一部分物理地址宽度来实现），这个特性叫做物理地址位超卖（oversubscribing）。该特性使物理地址具有了别名，即具有相同物理地址的页可以有不同的KeyID。
KeyID信息是不会出现在处理器外部的（比如内存总线上）。物理地址位超卖不会影响cache和TLB的行为，因为KeyID仅被当做成物理地址的一部分来处理；但物理地址位超卖会影响大多数的页表类型：Host普通IA页表、EPT和IOMMU页表。
IA paging
MKTME会影响Host侧的IA paging（含每一级页表），即在物理地址字段的高位中包含KeyID字段；CR3寄存器也受此影响，也包含了KeyID。EPT paging
MKTME会影响EPT paging（含每一级页表），因为EPT用于将GPA映射到HPA，而HPA必须要包含KeyID。IOMMU paging
MKTME会影响IOMMU paging（含每一级页表），因为EPT用于将GPA映射到HPA(虚拟化场景下)，而HPA必须要包含KeyID。其他物理地址
其他的物理地址结构（如VMCS指针、物理地址位图等）也都需要包含KeyID。
虽然例子中Hypervisor使用的是KeyID 0，但Hypervisor具有特权，可以使用任意KeyID访问自己的加密内存，也能管理和设置每个VM所能使用的KeyID。
MKTME支持的密钥数量总是固定的，而具体数量由特定的处理器实现来决定。软件可以通过配置只使用其中的部分密钥，这组密钥被称为可用密钥。软件负责管理可用密钥，并可以使用可用密钥对任意一个内存页进行加密。
在软件不进行任何显式配置的情况下，MKTME引擎默认使用TME的平台密钥进行内存加密。MKTME也允许使用软件提供的密钥或处理器RNG生成的密钥。 在虚拟化场景中，Hypervisor负责管理每个VM所使用的密钥，并透明地对Guest OS实施加密保护（在这个场景中，可以将MKTME视为TME虚拟化技术）。
总而言之，MKTME希望在系统层面能够创建多个独立的加密内存domain。 这对用户来说也更加安全。
安全威胁模型分析
TME和MKTME的安全性依赖于特权软件（OS和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和Intel CPU。
目前Intel TDX(使用到了MKTME技术)做到了在被攻破的OS/VMM环境里也能够保护租户机密数据的强度，前提是租户必须信任Intel CPU。
Exclusion range
A single exclusion range is supported (for both TME/MKTME for KeyID 0 only) for special use cases such as BIOS memory ranges that are not generally available to the operating system. Once the physical addresses are set, no memory encryption is applied to this range.
参考资料: