悬在云计算头上的达摩克利斯之剑 ——对于 Meltdown 、Spectre 事件的进展与思考¶

Source: /Volumes/X9 Pro/ObsNotes/YoudaoYunNotes/我的资源/微信收藏/悬在云计算头上的达摩克利斯之剑 ——对于 Meltdown 、Spectre 事件的进展与思考.pdf Converted: 2025-12-10 12:18:06

悬在云计算头上的达摩克利斯之剑 —— 对于 Meltdown 、 Spectre

事件的进展与思考

2018-03-14 AWS 云计算

One of the basic rules of the universe is that nothing is perfect.

宇宙的基本规则之一就是没有什么是完美的。

——Stephen Hawking

谨以此缅怀伟大的物理学家与宇宙学家

史蒂芬 • 霍金

今天，我们邀请到 AWS 首席云计算技术顾问费良宏老师为大家分享他对于 Meltdown 、 Spectre

事件的思考 ——

全文字数： 5443

阅读时间： 17 分钟

一部 IT 的历史简直就是一部 “ 墙头变幻大王旗 ” 的传奇小说。若论起来近 40 年来始终屹立不倒、笑

傲江湖的企业， Intel 当属其中之一。在那本《硅谷百年史》书中，就不吝笔墨地描写了 “ 仙童的叛

徒 ” 戈登 • 摩尔、罗伯特 • 诺伊斯以及安迪 • 格鲁夫创业的传奇故事。从 1978 年推出的 8086 处理器到

今天握有 x86 处理器 80% 的市场份额，这一份骄傲何人能及？

电影《蜘蛛侠》里面有一句经典台词：

“With great power comes

great responsibility”

但这一次， Intel 却因为自己的傲慢与失误让我们记住了这两个关于 CPU 的硬件漏洞： Meltdown

和 Spectre ，也让我们不得不重新审视一下这个老而弥新的话题 ——云安全。

解释起来这一次事件的主角 Meltdown 、 Spectre 是比较麻烦的一件事，涉及到许多现在 CPU 体

系方面的复杂概念。众所周知 CPU 的性能是推动整个 IT 行业发展的重要动力。 53 年以来，半导

体行业的 “ 摩尔定律 ” 更多的得益于工艺上的创举，并让我们不断地体验到高性能的 CPU 所带来的

种种好处。但随着半导体集成度的不断提高，我们也非常担心摩尔定律是否已经趋近物理上的极

限？

为了保持 CPU 的发展势头，现代的 CPU 处理器创造性地采用了一些新的技术，其中预测执行

（ Speculative Execution ）、多分支预测（ multiple branch prediction ）、数据流分析（ data flow

analysis ）三项技术，一起构成了乱序执行（ out-of-order execution ）的技术基石。

在 80386 时代，指令是顺序执行的。到了 80486 ，引入了流水线（ Pipeline ），将一条指令执行的

步骤以流水线的方式解放出来，一下子 CPU 的吞吐量就因此提高了将近 3 倍！虽然性能有所提

高，但此时 CPU 还是严格按照指令的顺序串行执行的。但是人们还是不满足，试图解决流水线存

在的空转和分支的问题。于是在奔腾 II （ Pentium Pro ）面世的时候， Intel 在 CPU 中引入了乱序

执行技术。指令的执行方式从程序流驱动变成了数据流驱动，也就是只要部件的输入条件满足就

可以开始执行了。流水线的吞吐量由此而大幅提高。与此同时，预测执行技术也被引入进来。分

支预测会判断哪条分支最可能被执行，预测执行会直接取得那里的指令并立即执行。这样等分支

结果出来后，实际上那里的指令早就开始执行了，流水线上总是满负荷运转，从而榨干了 CPU 的

处理能力！

要注意的是，乱序执行和预测执行在遇到异常或发现分支预测错误的时候， CPU 就会丢弃之前执

行的结果，然后将 CPU 的状态恢复到乱序执行或预测执行前的正确状态，并选择对应正确的指令

继续执行。这种异常处理机制保证了程序能够始终正确地执行。但是问题来了， CPU 在恢复状态

的时候并不会恢复 CPU 缓存的内容，而我们今天介绍 Meltdown 、 Spectre 这两组漏洞正是利用

了这一设计上的重大缺陷，允许程序窃取当前在计算机上处理的数据。关于上面的原理可以归纳

为以下几点：

所有现代 CPU 在执行代码之前预先从系统内存中获取数据。
预取数据放置在内部寄存器和 CPU 高速缓存中，读取速度比系统内存快得多。
自 1993 年以来，几乎所有的 CPU 都发布了预取数据，而且大多数预取的数据都是预测的。
现在， Meltdown 和 Spectre 漏洞背后的根本问题是：可能会诱使 CPU 将任意数据预取到内部

寄存器和缓存中，这是 CPU 和操作系统本来可以防止的。

通过称为高速缓存定时侧通道攻击的先进技术，可以暴露预取数据。
攻击可以使用这些漏洞来逐步读取系统内存，而不在意任何保护机制。

通常情况下程序不允许从同一台计算上运行的其它程序中读取数据，但恶意程序可以利用

Meltdown 和 Spectre 来获取存储在其它正在运行的程序内存中的机密信息。这可能包括存储在密

码管理器或浏览器中的密码、个人照片、电子邮件、即时消息甚至关键业务文档。 Meltdown 和

Spectre 漏洞存在于在个人电脑、移动设备和云计算环境中的服务器上。特别是在云计算的环境

中，这两个漏洞的存在可能导致用户数据被恶意程序所窃取。更进一步，在云计算上 Spectre 比

Meltdown 影响更大。 Meltdown 可使未经授权的应用程序读取特权内存，并获取运行在同一云服

务器上进程的敏感数据，而 Spectre 可让恶意程序诱使虚拟机管理程序将数据传输到在其上运行

的用户系统。问题说到这里是否感到一股寒意，而我们还可以继续无视这个问题的存在吗？

为什么会起了这么两个名字

Meltdown 和 Spectre ？

Meltdown 的含义是熔断，意指该漏洞融化了通常由硬件强制执行的安全边界。

Spectre 的含义是幽灵、妖怪，名字的来源是基于这个漏洞根本原因 —— 预测执行。由于漏洞很

不容易修复，它将困扰我们很长一段时间。

Meltdown 打破了用户应用程序与操作系统之间最基本的隔离。这种攻击允许程序访问其它程序和操作系统的内存，并从而访问其内

容。

Spectre 打破了不同应用程序之间的隔离。它允许攻击者欺骗其它程序泄漏他们的秘密，即使该程序遵循了最佳的安全实践。事实上，

所述最佳实践的安全检查实际上增加了攻击的面积，并可能使应用程序更容易受到 Spectre 的影响。

如果计算机具有易受攻击的处理器并且未安装必要的操作系统补丁，那么就有可能泄漏敏感信息。无论是个人电脑，还是云基础设施，

都会受此影响。

Spectre 比 Meltdown 更难利用，但它也更难以解决。

论文： https://arxiv.org/abs/

1801.01207

论文： https://arxiv.org/abs/

1801.01203

如何检测 Meltdown 和 Spectre 漏洞的存在？

针对计算机的安全漏洞，我们通常会使用为其提供一个公共的名称，这个机制就是所谓的 CVE

（ Common Vulnerabilities & Exposures ，公共漏洞和暴露）。简单的说， CVE 是由 MITRE 维护

的信息安全漏洞名称标准。有了这个标准名称，我们就可以方便地在各种数据库中找到对应的信

息。到目前为止，这两个漏洞被发现有三个已知的变体：

• CVE-2017-5753 : 边界检查旁路， Spectre 漏洞

• CVE -2017-5715 : 分支目标注入， Spectre 漏洞

• CVE-2017-5754 : 无管理数据缓存负载， Meltdown 漏洞

由于这次危机的影响实在太大，自 2018 年 1 月 2 日 The Register 首次面向公众报道了这个事件之后

不久，相应的针对这三个变体的检测工具陆续公布出来。

spectre-meltdown-checker （ https://github.com/speed47/spectre-meltdown-checker ）是一个

开源的漏洞检测项目，通过运行它提供的一个脚本文件 spectre-meltdown-checker.sh ，就可以快

速地检测当前系统针对这三个变体的状态。

输出结果：

注意：

如果出现 STATUS ： VULNERABLE 字样，则证明系统存在风险。

此外， IAIK/meltdown

修补以及缓解的措施

缓解措施对性能的影响

（ https://github.com/IAIK/meltdown ）也是一个很有意思的项目。不仅可以验证系统是否存在漏

洞，还可以提供漏洞的很细节的演示。要注意的是，项目的代码在运行前需要我们手工编译一

下。

事实上，从根本上修补这两个漏洞目前是无法实现的。只有寄希望下一代的 Intel 采用全新的设

计，甚至可能需要对微处理器体系结构进行重大改变才可能完全杜绝 Spectre 漏洞。

就目前而言，最有效的对策也只是针对具体的问题采用缓解的方案。而缓解方案的前提条件是：

操作系统和受影响的应用程序代码必须打补丁。
为了完全防止 Spectre ， CPU 微码（ microcode ）或系统固件（ firmware ）需要更新。
操作系统的保护必须被激活。
在虚拟化环境中，为了防止所有已知的攻击，上述所有条件对于宿主机和被托管的虚拟机都必

须是有效。

需要注意的一点是，随着研究的深入或许还会有新的变体被发现，特别是 Spectre 漏洞。由于

Spectre 是一整类的攻击，所以一个补丁很可能无法完全解决。虽然这个漏洞的一些特殊案例已经

在处理，但网站上也说： “Spectre 不易修复，所以会长期困扰我们。 ” （详情请见 Meltdown and

Spectre 官方网站： https://spectreattack.com/ ）我们还需要持续地关注这个漏洞。

缓解措施对 CPU 性能的影响一直是这个事件中另一个值得讨论的话题。关于这个问题，最标准的

答案应该是性能的下降完全取决于其工作负载。对于这个问题，我们目前取得的共识包括：

• Spectre 缓解的性能下降取决于正在使用的 CPU 系列：其分支预测器越先进，用于防御攻击的

功能的影响就越大。

• Retpoline 技术（ Google 提出的针对 Spectre 的缓解技术，它涉及在编译器编译时让间接分支跳

转到不同的目标，减少易受攻击的乱序执行发生）在 Skylake 平台上不会产生缓解；但在 Skylake

上，其它的缓解技术对性能的影响较小。

• 在具有 PCID （ Intel 64 架构下的进程上下文标识符）特性的平台上， Meltdown 的影响会大大降

低。

总体来看， Linux 之父 Linus Torvalds 认为性能的下降应该在 5 ％左右。而对于服务器工作负载，

下表提供了一种参考：

Databricks 对这个问题，尤其是在 AWS 上运行的 Apache Spark 性能的影响也做了一些有益的测

试。按照他们的测试， AWS 上的 EC2 实例的性能的影响约在 2%-5% 。 [“While it’s difficult to be

conclusive given the lack of controlled experiments, we have observed a small performance

degradation (2 to 5%) from the hypervisor updates on AWS.”]

AWS 的公告以及资源

AWS 服务受影响情况以及建议采取的对策

2018 年 1 月 2 日，在关于 Meltdown 以及 Spectre 被公布出来的第二天， AWS 就在其官网上发布了

名为 Processor Speculative Execution Research Disclosure (v1) 的声明，告知了 Amazon EC2

将在接下来的几个小时内完成相应的保护，并提醒用户更新内核、升级补丁等。随着对问题研究

的深入以及新的缓解措施的出现，这个声明在接下来的日子里被不断地更新，截止到目前已累计

更新了 18 个版本之多。后续还可以通过下面这个网址持续关注相应的进展：

https://aws.amazon.com/cn/security/security-bulletins/AWS-2018-013/

此外，在 Amazon Linux Security Center 网站上，也提供了对于 CVE-2017-5753 、 CVE-2017-

5715 以及 CVE-2017-5754 的变化跟踪。对于 Amazon EC2 的用户，则可以在在 Processor

Speculative Execution – Operating System Updates 网站上得到关于 AWS EC2 支持的操作系统

补丁的情况，这些操作系统的版本包括： Amazon Linux & Amazon Linux 2 、 CentOS 、 Debian 、

Fedora 、 Microsoft Windows 、 Red Hat 、 SUSE 、 Ubuntu 等。

截止到目前， AWS 服务受此事件影响的状况如下：

Amazon Linux 存储库中提供了更新的 Amazon Linux 内核。在 2018 年 1 月 13 日或之后使用默认

Amazon Linux 配置启动的 EC2 实例将自动包含更新的软件包，该软件包包含最新稳定的开源

Linux 安全性改进，以便在内核中满足 CVE-2017-5715 的要求，并基于之前合并的内核页表格隔

离（ KPTI ），解决了 CVE-2017-5754 。用户必须升级到最新的 Amazon Linux 内核或 AMI ，以有

效地缓解 CVE-2017-5715 的流程到流程问题以及 CVE-2017-5754 在其实例中的流程到内核问

题。

Amazon EC2

PV 实例

Amazon EC2 机群的所有实例都受到了针对 CVE-2017-5715 、 CVE-2017-5753 和 CVE-2017-

5754 的保护，没有实例可以读取另一个实例的内存，任何实例也不能读取 AWS 管理程序内存。

对于绝大多数 EC2 工作负载，我们没有观察到有特别的性能影响。

截至 2018 年 1 月 12 日，完成了针对 AWS 平台的新英特尔 CPU 微代码部分，我们发现英特尔微代

码更新导致少量崩溃和其他不可预知的行为。这一变化缓解了这些少数情况下的这些问题。

到 2018 年 1 月 12 日，我们完成了对 AWS 平台的新 Intel CPU 微代码的取消激活部分，在那里我们

看到了少量的崩溃和其他由 Intel 微代码更新引起的不可预知的行为。这个影响仅涉及少数实例。

AWS Batch 、 Amazon EC2 、 Amazon Elastic Beanstalk 、 Amazon Elastic Container Service 、

Amazon Elastic MapReduce 和 Amazon Lightsail 的用户建议修补其操作系统。

经过对可用于此问题的操作系统补丁的持续研究和详细分析后，已确定操作系统保护不足以解决

半虚拟化（ PV ）实例中的 instance-to-instance concerns 问题。虽然 PV 实例受 AWS 管理程序

的保护，但强烈建议用户迁移到 HVM 实例类型以获得更长期的安全优势。

Fargate 和 LAMBDA

ECS 优化的 AMI

更新 Linux 内核

Elastics Beanstalk

ElastiCache

提供托管服务的 EC2 已完成修补，无需用户进行任何操作。

Amazon ECS Optimized AMI 版本 2017.09.g 已经发布，该版本包含针对此问题的所有 Amazon

Linux 保护。建议所有 Amazon ECS 用户升级到 AWS Marketplace 中提供的最新版本。

sudo yum 更新内核。按照 Linux 内核的任何更新标准，在 yum 更新完成后，需要重新启动才能

使更新生效。

所有基于 Linux 的平台已被更新了，以包含针对此问题的所有 Amazon Linux 保护。建议 Elastic

Beanstalk 用户将他们的环境更新到最新的可用平台版本。使用托管更新的环境将在配置的维护时

段内自动更新。

基于 Windows 的平台也已更新，以包含针对此问题的所有 EC2 Windows 保护。建议用户将基于

Windows 的 Elastic Beanstalk 环境更新为最新的可用平台配置。

EMR

RDS

ElastiCache 管理的用户缓存节点都是专门为单个用户运行的缓存引擎，没有其他用户可访问的进

程，也无法让用户在底层实例上运行代码。随着 AWS 已经完成对 ElastiCache 底层的所有基础

设施的保护，此问题不会给用户带来风险。

Amazon EMR 将在用户的账户中运行 Amazon Linux 的 Amazon EC2 实例集群。在 Amazon

EMR 集群的实例中，关注进程隔离的用户应该按照上面的建议升级到最新的 Amazon Linux 内

核。最新的 Amazon Linux 内核已经集成到新的小版本 5.11.1 、 5.8.1 、 5.5.1 和 4.9.3 中。用户可

以通过这些发行版创建新的 Amazon EMR 集群。

RDS 管理的用户数据库实例都是专门为单个用户运行数据库引擎，而没有其他用户可访问的进

程，也无法让用户在底层实例上运行代码。随着 AWS 已经完成对 RDS 基础的所有基础架构的保

护，此问题不会给用户带来风险。目前大多数数据库引擎 RDS 支持都报告没有已知的进程内问

题。

对于 RDS for SQL Server 数据库实例，已发布了包含以下引擎版本中 Microsoft 修补程序的操作

系统和引擎修补程序：

SQL Server 2017 （ 14.00.3015.40.v1 ）

SQL Server 2016 （ 13.00.4466.4.v1 ）

SQL Server 2014 （ 12.00.5571.0.v1 ）

AWS 上的 VMware 云

SQL Server 2012 （ 11.00.7462.6.v1 ）

SQL Server 2008 R2 （ 10.50.6560.0.v1 ）

用户应该查看微软关于应用这些补丁并在选择时应用补丁的指导：

https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server 。

对于 RDS PostgreSQL 和 Aurora PostgreSQL ，以缺省配置运行的数据库实例当前不需要用户操

作。一旦可用，将为 plv8 扩展的用户提供适当的补丁。同时，启用了 plv8 扩展（默认情况下禁

用）的用户应考虑禁用它们并在 https://github.com/v8/v8/wiki/Untrusted-code-mitigations 上查看

V8 的指导。

MariaDB ， RDS for MySQL ， Aurora MySQL 和 RDS for Oracle 数据库实例的 RDS 当前不需要

用户操作。

根据 VMware 的说法， “ 自 VMSA-2018-0002 中记录的补救措施自 2017 年 12 月初以来一直存在于

AWS 上的 VMware Cloud 中。 ”

有关更多详细信息，请参阅 VMware 安全与合规博客，并参阅 https://status.vmware-services.io

以获取更新状态。

Workspace

对于 Windows Server 2008 R2 的 Windows 7 用户的体验：

微软针对此问题发布了针对 Windows Server 2008 R2 的新安全更新。这些更新的成功部署需要

服务器上运行的兼容防病毒软件，如 Microsoft 安全更新中所述： https

://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security- 更新和防病毒软

件。 WorkSpaces 用户需要采取措施才能获得这些更新。请按照以下 Microsoft 提供的说明进行操

作： https ://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-

against-the-speculative-execution 。

对于 Windows Server 2016 的 Windows 10 用户的体验： AWS 已将安全更新应用于在 Windows

Server 2016 上运行 Windows 10 的 WorkSpaces 。 Windows 10 内置了与这些安全更新兼容的

Windows Defender AntiVirus 软件。不需要进一步用户端的操作。

WorkSpaces Application Manager （ WAM ）

建议用户选择以下其中一种方案：

选项 1 ：按照 Microsoft 提供的步骤，在运行 WAM Packager 和 Validator 的实例上手动应用

Microsoft 更新，网址为： https://support.microsoft.com/en-us/help/4072698/windows-server-

guidance-to-protect-against-the-speculative-execution

此页面提供了更多说明和相关下载。

反思

选项 2 ：终止现有 Packager 和 Validator 实例。使用标记为 “Amazon WAM Admin Studio

1.5.1” 和 “Amazon WAM Admin Player 1.5.1” 的更新 AMI 启动新实例。

到目前为止，几乎所有的云平台的提供者都在认真地对待这一次的威胁。以 AWS 为例，在最短的

时间内在其规模巨大的基础设施上针对 Meltdown 和 Spectre 的漏洞完成了修补。并且没有迹象表

明存在可用的漏洞攻击针对这些云计算平台。从这个方面来说，云计算企业的技术能力以及运维

水准在这一次事件中得到了最好的证明。万幸，这一次并没有因为池鱼之殃而酿成云计算的灾

难。但是从根本上解决类似 Spectre 这种存在 20 年之久的根深蒂固的漏洞，恐怕不是一件简单的

事情。云计算上安全的挑战依然存在。经过 10 余年的发展，云计算平台几乎可以满足我们所有关

于互联网的想法。很难想象互联网上的数据、信息以及服务并不依赖诸如 AWS 这样的平台。从实

质上说，云计算几乎就是今天的互联网。虽然这些云计算企业拥有世界上最好的安全团队，但攻

击面几乎是无限的并且是无法预测的。处理来自诸如 Spectre 这一类的威胁将是系统所面临的最

严峻的安全问题之一 , 这是一个不会很快消失的问题。此外，在 “ 责任共担模型 ” 下，云计算的用

户也必须要承担起自身的职责。这一次的事件中，如果缺少了云用户的参与和配合，恐怕焦头烂

额的就应该是我们每一位了。

最后，针对这次事件我看到的一个最为大胆的说法来自于 ZDNet 。他们文章的标题就是 “ 为什么

Intel x86 必须死亡，我们认为以云为中心的未来取决于开源芯片 ” 。有意思的说法，谁知道这会不

会发生呢？

想联系 AWS 技术专家？

马上点击 “阅读原文 ”

阅读原文