LWN: memory加密方案讨论

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

来源: mp.weixin.qq.com

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

本文转载自:http://mp.weixin.qq.com/s?__biz=Mzg2MjE0NDE5OA==&mid=2247483815&idx=1&sn=6e2ce951ec2f7bf5c343b0fbf8b3ffcd,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有。

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加密方案讨论


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

关注码农网公众号

关注我们,获取更多IT资讯^_^


查看所有标签

猜你喜欢:

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

Building Web Reputation Systems

Building Web Reputation Systems

Randy Farmer、Bryce Glass / Yahoo Press / 2010 / GBP 31.99

What do Amazon's product reviews, eBay's feedback score system, Slashdot's Karma System, and Xbox Live's Achievements have in common? They're all examples of successful reputation systems that enable ......一起来看看 《Building Web Reputation Systems》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

SHA 加密
SHA 加密

SHA 加密工具

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

html转js在线工具