Linuxeden开源社区几年前，Google 工程师开始探索 Linux 内核的地址空间隔离，并最终提出了 Linux ASI 以更好地应对 CPU 推测执行攻击。虽然希望它能更好地应对不断增加的 CPU 推测执行漏洞列表，但最初由于 I/O 吞吐量性能损耗高达 70%，这一努力受挫。这种程度的性能损耗是不可持续的。但现在 I/O 开销已经降低到仅 13%。
Google 工程师 Brendan Jackman 再次将 ASI 带回到 Linux 内核开发者面前，因为“ASI 现在很快了…我已经准备了一个最新的 ASI 分支，展示了解决页面缓存性能灾难的技术…这个原型的目标是增加人们对 ASI 作为一种广泛解决 CPU 漏洞方案的信心。如果社区仍然需要为每一个单独的漏洞开发和维护新的缓解措施，因为 ASI 只适用于某些特定用例，那么考虑到其复杂性负担，ASI 的吸引力就不大了。建立这种信心的最大障碍是 Google 的部署仍然只使用 ASI 来处理 KVM 工作负载，而不是裸机进程。而且确实，页面缓存成了一个巨大的问题，Google 内部还没有遇到过。”
使用 FIO 进行随机读取时，仍然受到了 13%的性能下降影响，但至少比 70%的好。当前形式的 ASI 也增加了 Linux 内核编译时间 6~7%。Jackman 补充说：
尽管我的标题如此，这些数字说实话还是有些令人失望的，这并不是我现在想要达到的水平，但与几个月前原生 FIO 的情况相比，仍然好了一个数量级。我认为剩余的大部分性能下降主要是由于不必要的 ASI 退出，关键领域包括：
– 在每次 context_switch() 时。Google 的内部实现已经解决了这个问题（我们只需要在切换 mms 时使用它）。
– 在从分配器零化敏感页面时。这可能通过使用 ephmap 来解决，但需要小心以避免打开 CPU 攻击窗口。
– 在用户页面的 copy-on-write 时。ephmap 也可以在这里提供帮助，但当前的实现不支持这一点（它只允许每个上下文一次分配）。
通过这个 LKML 线程，现在希望是弄清楚状态是否已经足够好，以便 ASi 的工作可以继续进行，并有可能合并到 Linux 内核中。
所以，x86 的朋友们：这对你来说是不是“一线希望”？如果不是，那会是什么样子？我应该运行哪些实验？
我们看看 Linux ASI 会怎样发展。
转自 Linux Address Space Isolation “ASI” Revived After Lowering 70% Performance Hit To 13% – Phoronix