内存加密都有对应的加密部件属于“硬件加密”，不同厂商的CPU提供不同的加密特性。

一、INTEL的加密技术

针对不同场景INTEL提供如下内存加密技术：TME，MKTME，SGX。

TME（total memory encryption）

针对裸金属场景。该特性的保护域为DIMMs，使用唯一的master key对整个内存进行加密。信任域包含了host os，hypervisor以及vm。

适用性：

TME加密方式完全对软件透明，无需任何软件修订即可使用，适用性好。

安全性：

TME可以防止dump dimm的方式获取用户信息。 但是它的信任域范围过大，host os，hypervisor，vm 使用同一个key且相互之间没有隔离。一旦host os，hypervisor出了问题都有可能泄露vm内的用户数据。 极端情况甚至有可能通过一个被攻破的vm 访问其它vm的用户数据。因此它的安全性并不高，不太适合vm场景。

MKTME（multi-key total memory encryption）

针对虚拟化场景，该特性的保护域为单个vm，每个vm对应一个专有加密key。MKTME最多支持64个key，所以最多可以同时对64个vm的数据加密。它的信任域包含hypervisor和vm。

适用性：

采用这种方式必须修订host os和hypervisor。目前Linux内核，KVM QEMU的支持社区正在开发中。

安全性：

MKTME与TME相比最大的优势就是不同vm使用不同的加密key，vm之间利用不同的key实现了隔离保护，提高了vm数据的安全性。但是该特性实现必须依赖hypervisor进行key的分发和管理，所以hypervisor 必须位于信任域内。这意味着hypervisor 有能力“窥探”所有vm的内存数据，一旦hypervisor出了问题用户vm的数据仍然无法得到保护。因此安全性方面并不十分完善。

如下为MKTME 工作示意图，可以看出不同的vm使用不同的key来加解密使用不同的内存区域， vm间使用的内存区域都是相互隔离的。

SGX (Software Guard Extensions) 

针对APP数据保护场景：该特性保护域为app指定的内存数据，信任域为app自身。

实现方式：

每个app都可以通过专有的指令创建一个属于自己的enclave 并且把内存页“添加”到自己的enclave中，这些内存页被称为“EPC page”。

CPU 确保：

1）除了app自身以外其它任何组件（os，hypervisor，其它app）都无法访问该app分配的EPC page。

2）app 要访问自身的EPC page时必须调用专门的指令进入enclave mode才行，这意味着app内部可以做到普通数据和关键数据的完全隔离。

适用性：

guest os和用户APP 必须全部修订，修订成本较大，推广较难适用性很低。

安全性：

该方案除了app自身以外不信任何其它软件（os，hypervisor，其它app）安全性非常高。

性能影响：

该特性的使用会影响app 运行性能。

下图简单描述了SGX的大致工作原理。

二、AMD 提供的内存硬件加密技术

1. 用于裸金属场景的SME技术对标intel 的TME技术，用于对整个内存的加密。
2. 用于虚拟机场景的SEV技术用于对标intel的MKTME技术，用于对vm内存加密。

AMD缺乏一种类似SGX的技术用于APP级别的内存加密，不过AMD的内存加密技术也有自身的特点和优势。

和intel内存加密特性类似AMD加密特性同样使用了key机制，不同之处在于它还额外提供了C-bit位选择页加密机制，该机制允许只针对特定内存页进行加密。具体来说os和hypervisor可以通过设置页表项（PTE）的bit 47 位（c-bit）来表明是否对该内存page页加密，这种机制的使用大大增加了灵活性。Key机制和C-bit机制构成了AMD内存加密特性的核心。

SME（Secure Memory Encryption）

使用唯一key来加密内存， 可以细分为全内存加密模式和部分内存加密模式，该特性用于裸金属场景。

全内存加密模式（TSME）

优缺点非常类似intel的TME，这里不在详细解释。

部分内存加密模式

开启这种模式可以仅对特定的部分加密（实现原理就是前文描述的c-bit机制），例如可以仅对vm 加密或特定的app加密，os自身不会加密，因为加解密工作本身会有一定负载，所以某些环境下使用该特性会有性能上的优势。 其它优缺点和intel 的TME 模式类似。

SEV （Secure encrypted virtulization）

这种模式用于虚拟机场景的内存加密，使用不同的key对vm加密和hypervisor加密，每个key对应一个vm，SEV一共支持511个key，因此它最多可以支持510个vm的加密（还有一个key用于hypervisor），该个性保护域为单个vm，它的信任域为vm。

适用性：

采用这种方式必须修订host os，hypervisor以及guest os。目前主流的host os，guest os均已支持，qemu 和docker container均有对应的补丁。（稍后会介绍为什么guest os 也需要支持），适用性比MKTME特性稍弱。

安全性：

和intel的MKTME技术相比，它最大的区别在于hypervisor 不再负责管理key，向vm分发key。这意味着hypervisor 不再具有“窥探”vm内存的能力。此外hypervisor也可以使用自身的key来加密自身内存，这样它和vm之间也实现了数据的加密隔离，大大提高了安全性。安全性要优于MKTME。

SEV特性引起的技术问题：

hypervisor和vm使用不同的key隔离加密无疑是个优点，不过也带来一个技术难题: 在虚拟化场景中vm和hypervisor常常需要共享部分数据，那么如果数据被加密了它们又如何实现数据共享的呢？

SEV技术中信任域为vm，因此它认为vm中的guest os 是可信的， guest os 利用c-bit 技术解决了数据共享问题。如下图所示，对于需要和hypervisor交互的内存guest os不会使用vm私有key对它加密（可以交由hypervisor 使用自身key加密）。正是因为这个原因在使用SEV特性时，guest os 必须修订到合适的版本。

性能：

SEV 加密性能较为出色，经测算加密后性能损失约为0-3%。

除了内存加密特性外AMD还提供了另外的两种高级安全特性。

SEV-ES（Encrypted state）：

它的作用是对vm的寄存器加密，加密后hypervisor无法读取vm的寄存器信息，进一步提高了vm的安全性。目前KVM的支持社区正在开发中。

SEV-SNP（Secure Nested Paging）：

该特性声明了每个内存块的owner，每个组件（os，hypervisor，vm等等）只能访问自己的内存块，提供了更严格的内存保护措施。

SEV-SNP的实现原理：

硬件新增一个RMP表，该表类似页表，每4k内存page都对应一个表项，每个表项纪录了该page的owner。组件访问内存时首先经过页表找到对应物理地址，然后会依据物理地址查找PMP表确认该物理地址的owner，如果访问该物理地址的组件并不是它的owner 那么该次访问就会报错。

注意

SEV和SEV-SNP功能区别在于，SEV 负责的是内存加密，SEV-SNP负责的是内存读取权限。简单的说仅使用SEV 特性理论上一台vm还是有可能获取另一台vm的数据，不过获取数据是加过密的并没有什么用。如果再开启SEV-SNP 那么一台vm甚至不可能读取到另一台vm的数据。

三、总结

以上介绍了INTEL和AMD的几种内存加密技术，从加密粒度划分可以分为全内存加密，vm加密，APP加密三类。对标两种CPU 可以大致得到下表：

INTEL		AMD
TME 裸金属场景	适用性好，安全性差	适用性好，灵活性好，安全性差	SME 裸金属场景
MKTME 虚拟化场景	适用性较好，安全性较差，目前性能差	适用性略差，安全性较好，性能不错	SEV 虚拟化场景
SGX APP加密场景	适应性很差，安全性非常好		无
无		用于保护vm的内部寄存器信息	SEV-ES 虚拟化场景
无		用于限制内存读取权限控制等	SEV-SNP 虚拟化场景