内存加密都有对应的加密部件属于“硬件加密”，不同厂商的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 提供的内存硬件加密技术
- 用于裸金属场景的SME技术对标intel 的TME技术，用于对整个内存的加密。
- 用于虚拟机场景的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 虚拟化场景 |
