熔断易挡，幽灵难防

硬件层面的修复对我们来说都是空谈。操作系统层面，各主流操作系统这两天都已经陆续推了针对 Meltdown 的修复补丁。主要是一种研究人员推荐叫做 KAISER 的方案，在 Linux 内核更新中这项特性叫 KPTI（内核页表隔离）——其实现方法是，让内核不要映射到用户空间中。这种方案其实早两年就有了，当时是为了杜绝攻破 KASLR 的边信道攻击提出的。

国外网友最早发布的 FS-Mark 测试，显示在打完 KAISER 补丁前后，Coffee Lake 的 I/O 性能差别可超 50%——当然了，这应该只是个案[12]

不过巧合的是，它也能预防 Meltdown 攻击，因为内核空间或物理内存在用户空间中已经没有有效的映射了。提出相对完整的解决方案的 paper 就是去年发布的，研究人员在 paper 中将这套方案称为用于内核地址隔离非常“高效的实践系统”[11]，号称对性能影响仅有 0.28%。文中提到，实验中发现禁用全局比特位（也就是标记权限的比特位）对于性能的影响竟然是微乎其微的，而且当代 CPU 对于 TLB（可以看做是内存页的映射）的优化对性能影响并不会太大。有兴趣的可以去研究下这套方案，虽然 0.28% 这个数字很值得商榷。

毫无疑问，KAISER 对 I/O 性能会造成一定影响，因为 KAISER 的这套方案设计了个 Shadow 地址空间页结构，去掉了标记权限的全局比特位，需要频繁切换 CR3 寄存器，并清除非全局的 TLB 项。根据现在的测试，应用KAISER补丁之后可以观察到高性能NVMe设备、网络互联设备有明显的性能下降。

Intel 方面已经确认，针对八代酷睿芯片，补丁会造成 6% 的性能下滑——只不过大部分计算机用户并不会造成太大的影响，主要在日常使用方面并不会有明显差异[13]。Intel 甚至还主动公布了跑分测试结果[14]，就近两代酷睿产品，使用涉及复杂 JavaScript 操作的 web 应用的用户可能受到最大影响，补丁前后的最大差别可达 10% ，游戏等图形密集型工作负载或财务分析等计算密集型工作负载受到的影响最低。第六代 Skylake-S 平台性能影响可能稍高，SYSMark 2014 SE 测试总体差距在 8% 左右。

微软方面也已经发布声明[15]，提到：

– 针对 Skylake、Kaby Lake 及更新的 CPU，Windows 10 系统在性能方面仅有百分比个位数的下滑，而且大部分用户基本是察觉不出来的；

– 针对 Haswell 及更早的 CPU，Windows 10 则在性能方面会有“更为显著的下滑”，“部分用户会察觉到系统性能的下降”；

– Windows 7/8 的情况更早，Haswell 及更老的 CPU 用户，绝大部分都会感知到系统性能的下降。

同时微软还提到，对于运行 Windows Server 的任意 CPU，尤其是对 I/O 操作比较敏感的服务任务，“作为缓解方案，如果在 Windows Server 实例中隔离不受信任的代码，性能方面会有更为明显的影响”。所以微软建议服务器用户，在安全和性能之间做出更为权衡的选择——这也是我们能够看到的，为数不多微软针对 IT 管理员给出这样的说辞。

值得一提的是，KAISER 本身也存在一定的局限性，鉴于 x86 架构的设计，某些高权限内存位置必须映射到用户空间。这仍然留下了一小撮攻击面，这些内存位置仍然可从用户空间读取，只不过这些内存位置并没有什么敏感信息——但善加利用，比如这些位置仍然可以包含指针，打破 KASLR 也就成为可能了。

另外，针对 Spectre，目前并没有真正行之有效的根治方案，包括 KAISER 对 Spectre 也是没用的。原 paper 提供的一些缓解思路并不能从根本上杜绝 Spectre 攻击。Meltdown 与 Spectre 官网在 Q&A 中表态说[16]，修复 Spectre 并不容易，未来可能会困扰我们很长一段时间；补丁会让攻击变得更困难。

性能与安全的割裂是否将永远持续？

Meltdown 和 Spectre 两者几乎影响到当代所有的电子设备，包括笔记本、笔记本、智能手机，以及对企业而言悲剧的云服务器。但凡操作系统（微软、苹果、谷歌、Linux）、芯片制造商（苹果、三星、Intel、AMD 等）似乎都在慌忙地对这次事故做响应，尤其 Intel 公关，以为去年忙完 Zen 的灭火之后今年得交好运了，没想到碰上这么个事儿。但从微软去年 11 月的动作来看，大约 Meltdown 的修复从来不是最近才开始的。

不过对个人设备的 Meltdown 和 Spectre 攻击，初始攻击向量要么是恶意程序，要么是 web 端的恶意链接：这仍然是需要用户去交互的，比如引诱用户下载恶意程序，或者点击某个恶意链接。但在云平台就不同了，The Verge 认为，这次漏洞波及最大的应该是云计算，毕竟云平台是个更大的威胁空间。一台云服务器上，就会有好些租户，所以亚马逊、谷歌、微软、阿里也都全面卷了进来。如 paper 中对虚拟环境的测试那样，meltdown 要针对同一台云主机上的其他租户窃取数据，也是完全可行的。大量中小型企业的基建现如今就在云上，这样一来隐患就显得相当之大。主要的这几家云服务提供商也已经很快打上了补丁，谷歌发言人说，其云服务器现在已经不受 Meltdown 和 Spectre 影响，但没有透露究竟是怎么保护 Spectre 的[17]。

硬件层面的某一种优化就会带来微架构元素的状态改变，并危及安全软件的实施——这其实是 20 年前的一个共识[18]。比如说出现一个漏洞，是由于硬件优化导致微架构状态的变化，如果某种加密算法没有及时针对可能出现的泄露做防护，就会产生这样的 BUG。不过 Meltdown 的出现颠覆了现状，因为攻击者甚至可以读取每个比特位，而无视精度问题，这是任何算法改进都无法做出防护的。就我们而言，唯一可以冠冕堂皇对企业做出的建议就是：把安全融入到开发中去。

信息安全行业现如今正在给企业、互联网产品灌输一个理念，即将安全融入到开发环节中去，而不是在开发结束后再检测安全问题——虽然这可能只是安全行业希望赚到钱的忽悠。这其实是相当理想化的一种开发理念，开发和安全一直以来都有不可逾越的鸿沟，光是开发人员和安全人员两者技能倾向性上的不同，而且开发和安全的职能是完全不一样的，安全在很多管理者眼中除了烧钱并没有什么卵用。就好像 Intel 的工程师们大部分都并非安全专家，何况 AMD 最近给的压力这么大，再说这次的攻击还是用了边信道这么赖皮的方法，任谁也很难想到。所以这种“融合”会不会发生需要打个巨大的问题。

但 MIT 的一份研究显示，去年一年召回的植入式医疗 IoT 设备达到 150 万台，都是因为安全问题，其中还包括心脏起搏器——这个数字听来似乎并没有很庞大。如果说现如今的某些硬件遭遇安全问题，比如这次的处理器漏洞，还能在操作系统层面加以弥补，那么医疗 IoT 设备出现安全问题就没有这种可行性了。而且这种程度的召回已经不仅限于企业的经济损失，更关乎到用户本身的生命健康，还要考虑召回的难度问题。随着工业 5.0 时代的到来，未来不光是医疗设备，植入式设备、VR/AR 设备的出现可能会越来越常见，比如可能出现植入人体的娱乐设备、传感器，那么当他们出现严重的安全问题时，我们又该何去何从？或许开发和安全的融合会是为数不多的一条思路，至少能够缓解安全问题。

参考资料：

[1]Linux 设备 TCP 连接的有趣漏洞：传说中的 Off-Path 劫持
[2]Reading privileged memory with a side-channel
[3]FLUSH+RELOAD: a High Resolution, Low Noise, L3 Cache Side-Channel Attack
[4]Spectre Research Paper
[5]Cache Template Attacks: Automating Attacks on Inclusive Last-Level Caches
[6]Meltdown Research Paper
[7]Retpoline: a software construct for preventing branch-target-injection
[8]Mitigations landing for new class of timing attack
[9]Site Isolation – The Chromium Projects
[10]Negative Result: Reading Kernel Memory From User Mode
[11]KASLR is Dead: Long Live KASLR
[12]Initial Benchmarks Of The Performance Impact Resulting From Linux’s x86 Security Changes
[13]Intel Offers Security Issue Update
[14]Blog Benchmark Table – Intel
[15]Understanding the performance impact of Spectre and Meltdown mitigations on Windows Systems
[16]Meltdown and Spectre – Vulnerabilities in modern computers leak passwords and sensitive data
[17]The CPU catastrophe will hit hardest in the cloud
[18]Timing Attacks on Implementations of Diffe- Hellman, RSA, DSS, and Other Systems