LWN: memory加密方案讨论

栏目: 编程工具 · 发布时间: 4年前

内容简介:全文完极度欢迎将文章分享到朋友圈长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

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的锁保护,但是用户其实希望的是更细粒度的保护。

LWN: memory加密方案讨论 简单来说,就是希望在系统里面能创建多个独立的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就必须要保存

LWN: memory加密方案讨论 一套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本身是怎么生成的也就没有多大意义了。

全文完

极度欢迎将文章分享到朋友圈 

长按下面二维码关注:Linux News搬运工,希望每周的深度文章以及开源社区的各种新近言论,能够让大家满意~

LWN: memory加密方案讨论


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

面向对象技术UML教程

面向对象技术UML教程

王少峰 / 清华大学出版社 / 2004-2 / 24.00元

《面向对象技术UML教程》主要介绍统一建模语言UML及其应用。全书内容丰富,包括UML的用例图、顺序图、协作图、类图、对象图、状态图、活动图、构件图和部署图等9个图中所涉及的术语、规则和应用,以及数据建模、OCL、业务建模、Web建模、设计模式、OO实现语言、RUP等方面的内容,同时介绍了Rose开发工具中的一些用法。《面向对象技术UML教程》最后是一个课程注册系统的实例研究,以及一些思考题和设计......一起来看看 《面向对象技术UML教程》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

html转js在线工具
html转js在线工具

html转js在线工具