LWN：呼吁再次考虑地址空间隔离！
关注了就能看到更多这么棒的文章哦～
A call to reconsider address-space isolation
By Jonathan Corbet
September 29, 2022
LPC
DeepL assisted translation
https://lwn.net/Articles/909469/
内核运行时可以访问到地址空间中的全部内容，通常就包括了所有的物理内存，尽管其实这个地址空间中只有一小部分是内核实际需要访问的。这就导致内核面对投机性攻击（speculative attack）的时候比较脆弱。近几年一直有一个希望能改变这种情况的地址空间隔离（address-space isolation）patch set，但从未被认真考虑过合入 mainline。在 2022 年的 Linux Plumbers 会议上，Ofir Weisse 试图说服开发社区来重新考虑一下地址空间隔离的事情。
Weisse 首先指出，看起来源源不断地有新的投机执行攻击，都需要应对；"Retbleed "只是最新的例子之一。要想补上这些漏洞，带来的性能开销可能会很高，以至于很多公司根本不使用这些防护措施。开发也非常耗时，每一个新的这类攻击，都需要几个月的努力工作才能解决。
地址空间隔离（ASI，Address-space isolation）是把不再需要的内存 unmap 掉的一个技术，从而让当前的运行环境无法访问到这部分内存。投机执行攻击就不再能访问到那些未被 map 的内存，因此这些 unmmaped memory 中的内容就不能再通过这种攻击而被泄露出来。ASI 的例子之一就是 kernel page-table isolation，这个机制是在应对 Meltdown 漏洞时实现的。近年来，有许多建议都是关于在其他一些情况下使用 ASI 的，但没有一个被合并到 kernel。本次会议讨论到的这个具体的提案，就是希望能保护 host 免受恶意虚拟机的攻击。
Weisse 说，在内核中更广泛地使用 ASI，就可以减少防御投机性漏洞所做的许多工作。它将把解决一个新漏洞的工作减少到 "由一个工程师编写三到十行代码" 的程度，而且不会对性能产生新的影响。不过，这个说法中的 "新" 这个字很重要；ASI patchset 本身对性能是有 2-14% 的影响的，取决于运行哪个 benchmark。他说，这些数据还有改进的余地。
他继续说，这个 patch set（https://lwn.net/Articles/886494/ 有更详细的描述）是 "一粒苦口良药"。这个 patch 很大，需要对内存管理子系统和许多分配函数（如 kmalloc()）的调用进行较多的修改。简而言之，ASI 需要对内存的 "内容敏感" 部分进行标记，这部分应该被屏蔽掉从而避免投机执行攻击；这些部分在隔离生效时会被 unmmap 掉。这意味着会需新增一些 GFP 标志来用在内存分配时，以及在 slab 创建和 vmalloc() 的时候使用一些类似 flag，还有需要对局部变量和全局变量增加一些新的 annotation。完整的工作中需要检查每一个分配和声明的位置，并确定所涉及的内存是否算是敏感数据。
在内核把控制权交给一个虚拟机时，它首先会调用 asi_enter() 来对所有被标记为敏感数据的内存进行 unmmap，使这些内存无法被投机性攻击所获取。在这个虚拟机退出回到 host 内核时，如果 host 内核处理来自虚拟机的请求，那么该内存起初还是会保持在 unmapped 状态。他说虚拟机退出的原因中，许多都是可以在不访问敏感内存的情况下进行处理的。在这种情况下就把这个 request 处理掉了，然后将控制权返回给虚拟机，而不需要把那些敏感内存 map 上来。
但是，有时会有需要去访问这些敏感内存。Weisse 说，这里观察到的一个重要特征是，那些 speculative 执行永远都不会导致 page fault。因此，如果内核在试图对敏感内存进行操作时出现 page fault，就说明这种访问应该不是 speculative 性质的；内核就可以把这部分内存 map 上来从而继续执行。如果同时正在使用 SMT（simultaneous multi-threading），相应的兄弟 CPU 都会将在 map 这个内存之前就被 "击晕"（也就是强制进入 idle），从而额外确保安全。在返回虚拟机时，该内存区域会被再一次地 unmmap 掉，兄弟 CPU 也会被恢复正常。
使这一机制良好运作的关键是要确定哪些内存应被归类为敏感内存。如果能有更多的请求可以在无需 map 敏感内存的情况下处理掉，那么就可以提高性能和安全性。这是通过运行人们关注的各种 workload 并查看需要 map 敏感内存的虚拟机退出 event 的百分比来实现的；理想情况下，这个数字应该很低。如果情况不是这样的话，就需要查看正在被访问的内存，并确定它是否是敏感内容，从而可以相应地改变分配位置的代码来正确地对内存进行标记。
Weisse 最后说到，ASI 可以让未来解决那些必定会出现的新的投机性执行漏洞变得更加容易，并且性能损失远远小于目前的缓解措施所带来的损失。他说，开发者们应该重新考虑一下，服下这颗苦口良药。
Dave Hansen 问，ASI 是否可以扩展到更普遍的 baremetal system 上，而不是专门针对 KVM 接口。Weisse 回答说，应该是可以的，但要做到的话，还需要很多工作。
Christian Brauner 问道，为什么该 patch set 以前被拒绝了。发布了最新版本代码的 Junaid Shahid 说，没有人真正反对这个想法，但也没有人很希望把它合入进来。Hansen 说，他不喜欢这个方案，因为它为了一个相当小众的使用场景编写了大量的代码；它也根本没有解决 system-call 路径上的问题。他补充说，需要确定内存的敏感性的话，会给内核中各个地方都带来很大的维护负担。
会议结束时，没有就这项工作的未来得出任何真正的结论。除非有一天出现了一波对 ASI 的热情欢迎，否则它似乎可能会无限期地在 mainline 之外徘徊。这颗药丸，对大多数开发者来说，似乎仍然太苦了。
[感谢 LWN 订户对编者参加这次活动的支持。］
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～