LWN: 如何更好地支持在内存中存放秘密信息？

点击上方蓝色“Linux News搬运工”关注我们~

Keeping memory contents secret

By Jonathan Corbet
November 15, 2019

原文来自：https://lwn.net/Articles/804658/

操作系统的众多职责之一，就是帮助确保进程之间的信息要隔离好，不要泄漏。不过很多时候操作系统在这方面做的并不好，原因有很多，例如硬件bug，或者user-space的漏洞等，这些都超出了操作系统的直接控制了。因此，不出意料，越来越多的人在想办法能改善数据安全性，甚至连操作系统本身都不希望它知道。Mike Rapoport提出的MAP_EXCLUSIVE patch set就是一个例子，不过也揭示了一个事实：开发社区其实还没有想清楚应该如何使用这类功能。

MAP_EXCLUSIVE是mmap()系统调用的一个新增flag，目的是要求对这块memory区域映射出来后只允许调用者进程访问，绝不允许其他任何人访问，kernel也不行。这个patch是目前对内存管理子系统进行的地址空间隔离工作的一部分，因为攻击者很难访问到那些未映射过的memory。

使用MAP_EXCLUSIVE来映射一块内存区域的话，会有多方面的影响。首先它隐含了MAP_LOCKED和MAP_POPULATE这两个flag，意味着这块memory会马上触发page fault来映射到RAM并且lock（锁定）住——也就是说绝对不会进入交换区域（swap area）。并且还需要有MAP_PRIVATE和MAP_ANONYMOUSE flag，而不允许使用MAP_HUGETLB。如此映射过的page页面在进程fork的时候不会被复制。并且这块区域会从kernel的direct mapping（指对全部物理内存进行的线性映射）中拿掉，使得大多数情况下kernel也无法访问到这块内存。

社区里面都比较赞同新增MAP_EXCLUSIVE的这个目标，不过等这部分代码真正实现出来了，却引起了很多关于这个功能如何工作的疑问。有些人担心从kernel direct mapping中去除这些page会有问题。kerne对这类mapping都是使用huge page（巨页）方式，因为这样映射毕竟能降低TLB的压力，对性能有好处。如果要把这部分区域从direct mappping中拿掉的话，就需要把huge page分割成normal page，从而导致系统里面所有进程的性能都会下降。Alexei Starovoitov在10月份的时候分享过Facebook的一个按理，当时因为另一个原因把direct mapping改成normal page，就导致了2%的性能损失。

Elena Reshetova提出，她之前曾经开发过一个类似的功能，当时没有修改mmap，而是新增了一个madvise() flag，并且要求这块需要保密的内存区域要是page size的整数倍。她实现的代码里面，每当把这块保密内存区域还给系统的时候还会把这些数据全部覆盖掉，以备调用者进程本身没有做这个操作。

Reshetova还建议要把这块memory映射成uncached形式。好处是可以避免近年来泛滥的speculative-execution attach（执行预测攻击），无论是已知的攻击方式还是一些未公开的攻击方式。此外，它带来的对application的性能影响确实有不少（painful），不过还不至于达到完全影响功能（crippling）的程度，这取决于对这块memory的访问频率了。有些用户需要这个更多保护，而很多其他用户却不愿意为了这个功能而损失性能。Andy Lutomirski认为只有在application明确要求uncached memory的时候才配成uncached，不过Alan Cox则指出用户通常其实并不知道是否该用uncached memory。

Cox还指出，系统为了保护这些保密数据内存区域，会采用很多手段，并且不同的系统上采取的措施都可能不一样，用户完全不了解他的系统上会采用什么方式，因此，我们更加需要把MAP_EXCLUSIVE flag的效果定义得更加明确一些：“在我看来，这里真正的问题是我们需要一个明确的语义定义。你们到底是要什么？是愿意付出任何代价吗？需要100%保证可靠还是统计意义上可靠就好？保证到什么程度可以接受？什么情况下应该返回-EOPNOTSUPP之类的返回值？”

James Bottomley在此基础上也发挥了一下，他认为MAP_EXCLUSIVE有一个“可用性问题”。在某些系统上，要想保护保密数据，会需要利用一些硬件技术，例如TME和SEV。不过开发者通常不清楚这里有区别。Bottomley建议，kernel应该想些方法来选择最合适的硬件机制从而更好的保护保密内存。比如可以只在那些没有堵上speculative-execution漏洞的系统上把这块memory映射为uncached。Lutomirski担心这种方法没法实现，毕竟这里有太多变数了，很难保证不出错。

这一轮讨论只有一个真正达成的结论：确实有需求来让某块内存有更高的保密性，不过开发社区还不清楚究竟应该如何实现，以及怎样让用户来使用。这也意味着这个功能不会很快出现在mainline kernel里。如果设计得不好的话，可能会使社区又要背负一个有设计缺陷的接口，也有可能导致应用程序开发者没能得到应有的安全保护。我们应该慢慢来，确保做最正确的事情。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

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