LWN: memory加密方案讨论

Memory encryption issues

By Jonathan Corbet ,  May 1, 2019

LSFMM

LSFMM会议（2019 Linux Storage, Filesystem, and Memory-Management Summit）上，Dave Hansen开场提出：“大家都觉得memory encryption应该很酷吧，它肯定能让系统更安全，太棒了”。memory encryption就是指内存外存的数据加密。这场关于Memory encryption的讨论是由Dave和Kirill Shutemov一起主讲的，列举了Intel平台上memory-encryption方向的一些进展和问题。其中一个主要的结论，其实就是Hansen也在一开始就提出的：memory encryption的使用者必须想清楚这里更进一步的安全性究竟是从哪里来的，你是否愿意take。

Memory encryption有很多形式，Hansen主要讲了Intel的方案。这个feature主要是来自人们渴望保护数据的需求。普通RAM里面储存的data，在掉电之后，一般人都以为是彻底消失了。但其实在一些复杂的离线攻击方式（通常指不是通过网络进行的攻击）下，这些数据仍然是能被恢复出来、导致泄密的。persistent memory（外存，包括磁盘、SSD、eMMC等）的数据当然更加容易泄露。这些设备可能是有hardware lock的锁保护，但是用户其实希望的是更细粒度的保护。

简单来说，就是希望在系统里面能创建多个独立的encryption domain，也就是说每个container都能有不同的key。用户通常认为这样更安全一些。这类加密方式哪怕在被攻破的OS环境里也能够保护用户的数据安全，但是这个方式目前还没有实现。Intel这里投入了很多资源来做“multi-key total-memory encryption”（MKTME，多秘钥全内存加密）。此前的TME（全内存加密）只使用了一把秘钥，这样能把所有数据都保护起来，但是没能支持system里面划分出多个domain。MKTME就能够让不同的进程各自使用不同的秘钥（key）。现在已经有了MKTME对anonymous memory的patch实现出来了。Rik van Riel这里问了个问题，加密是否是CPU内部做的，尤其是存储在CPU cache里的数据是加密过的吗？答案是“no”。加密是在memory controller这里实现的。Van Riel就接着追问下去，他认为针对例如L1TF这样的攻击方式，这样的实现方案没有提供保护。Hansen也表示赞同，memory encryption方案并不会对speculative-execution攻击有什么保护效果。

Hansen提出另一个有意思的问题，看起来没有什么好的解决方案：有很多攻击是攻击encryption keys（加密秘钥）的，利用的方法是创建大量的数据加密。那么在MKTME这样的方案里，memory controller就变成了一个高速率的encryption engine加密引擎，这样可能会让上述的攻击方式变得更加方便。这样的一个考虑角度也是不能被忽视的，否则没法提供真正的更安全的方案。

有人问道memory encryption是否支持DMA I/O，这次答案是yes，可以做。不过支持DMA的话，就需要把加密秘钥写到IOMMU里面去。AMD的memory-encryption实现方案不是这么做的，而是用了bounce-buffering（就是把数据copy到一块专用于DMA的内存区间）。

Hansen说，还需要做很多工作，包括怎么实现对那些文件mmap出来的内存（或外存）做保护。这样最终就可以做到在device-level】、或者针对某个文件和目录，设置不同的key。这个方案估计会利用fs-crypt的功能，有一些文件系统已经支持fs-crypt了。

Van Riel问道，当前方案里面能支持多少组key？回答是每个memory controller支持64组不同的key。当前的patch实现里面，所有的controller都只能使用相同的key。有一些讨论希望能不要有这个互相依赖关系，而是每个controller可以拥有跟别的controller完全不同的keys秘钥组，这样就能增加总共可用的key slot的数量。不过Hansen指出这种方式会变成管理噩梦，因为通常分配内存的时候不会知道分到哪个controller去了，如果只有某些memory controller能支持某个特定进程的encryption key的话，这个系统实现起来太复杂了。当然如果某些数据是绑定到某个memory controller的话，这个实现就有意义了，例如送到某个persistent-memory的外设的数据，通常都是指定好的，不会去别的controller。

Shutemov简要提了一下CPU hotplugging引入的一些挑战。因为一个新的CPU可能会同时引入一个新的memory controller，这样意味着当前在用的controller的那组key也需要写到这个新的memory controller里去。要想实现这个功能，kernel就必须要保存

一套key在它自己的memory里面，这样攻击者就又多了个渠道可以窃取秘钥。通常攻击者没有办法能从memory controller里面把秘钥提取出来，所以只要kernel能把自己的那个copy删除掉，key-steeling attack（秘钥窃取）就差不多是一个不可能的任务了。因此如果把key保存在kernel里，纯粹是一个降低系统安全等级的动作，需要尽量避免。

最后，还有一些讨论关于MKTME patch是否允许用户对anonymous memory设置用户自己特有的key。讨论下来似乎这样做并没有什么安全性上的好处，其实恰恰相反，还真是有好处的。user-supplied key可以提供一种secure-erase功能，就是当某个用户的进程结束的时候，memory controller里面相应的encryption key可以被覆盖掉，这样这部分user data就无法访问了。

Matthew Wilcox提醒道，encryption虽好，但也会有缺点。这里的memory encryption会增加多少功耗呢？没有人知道这个数据。Hansen指出，memory latency这里确实有x%（百分比的一位数）的增长。总的内存带宽确实没有影响，不过latency确实增加了。在key更新的时候也有一些损失，因为配置key是一个特权操作，key slot也是有限资源，所以通常来说用户没法无限制的随意使用这个资源。

这个会议很快到时间了，最后一个问题是TME用到的key（这个key应该是boot阶段就有的key）是从哪里来的，用户怎么知道这个key是不是安全呢？目前没有一个明确的回答，不过Hansen指出这个key来自CPU，如果CPU本身都无法被trust，那么讨论encryption key本身是怎么生成的也就没有多大意义了。