虽然“芯片门”事件已经过去了，但“崩溃”（Meltdown）和“幽灵”（Spectre）两大安全漏洞的故事并没有结束。即使亚马逊网络服务（AWS）的响应显示他们已经修补并保护了他们的基础架构，但这不意味着您就可以什么都不做。AWS的共享责任模式意味着您负责修补EC2实例上运行的操作系统。这里有一些一般的规则要遵循：

1. 使用HVM虚拟化模式的最新AMI运行EC2实例；

2. 修补操作系统，以确保应用了Meltdown修复程序；

3. 更新到最新的EC2实例系列；

4. 运行最新的Linux内核，以确保您拥有PCID支持

这些漏洞存在于自2013年以来制造的所有Intel CPU中，允许恶意程序窃取通常被保护的信息，比如密码、信用卡号等，而这些数据是由CPU处理的。这是由于CPU本身的缺陷，与Windows、Linux、Mac OSX或任何其他操作系统无关。CPU是硬件不能被修补，因此我们必须依赖于在这些CPU之上运行的系统的修复。

通常有两类直接在CPU上运行的系统：一类是操作系统，如Linux或Windows。另一类是管理程序，如VMware ESXi、Xen或Amazon基于KVM的私有管理程序。如果在CPU上运行虚拟机管理程序，则会托管其他操作系统（如Linux和Windows）。

将补丁应用到第一层可以防止Spectre和Meltdown攻击，对性能产生不同程度的影响。在虚拟机管理程序之上运行的虚拟机仍然需要进行修补，以保护在其操作系统中运行的进程免受攻击。这些补丁本身也会应用潜在的性能影响。

自2010年以来，英特尔CPU（代号“Westmere”）支持了一项名为PCID的特性。在过去的7年中，Linux内核有些乏味并不被支持。安全。但从内核4.14开始，它得到了支持。

事实证明，PCID对于减轻KPTI补丁的一些性能影响是重要的，并且防止了一个应用程序在所有其他应用程序中杀死系统性能。您可以看到，内核维护了一个Translation Lookaside Buffer（TLB），这就像内核和用户态内存页面之间的映射索引。当系统调用通过用户区/内核边界时，在没有PCID支持的处理器上运行的内核必须丢弃TLB并重新启动，增加了执行频繁操作所需的时间。

但是，所有现代的CPU和Linux内核都支持这个功能，这也并不意味着可以在AWS上使用它。

HVM、PV和实例

AWS的原始EC2实例全部运行在一个管理程序之上，为访客操作系统提供半虚拟化接口，从而隐藏了底层CPU的一些功能，包括PCID功能。

更新的实例系列（以及一些较旧的系列）运行在一个更新的虚拟机管理程序上，该虚拟机管理程序提供了更多的底层功能。这个虚拟化模式被称为“HVM”，代表“硬件虚拟机”。

尽管几乎所有EC2实例系列（如t2、m3、c4）都可以在HVM模式下使用，但他们并不都暴露PCID功能，为了避免最差的性能损失，您需要PCID功能。

我们做了一些研究，并将EC2实例系列映射到虚拟化模式和CPU功能，以确定哪些组合受到的影响最小。如下表所示：

您可以看出，避免那些没有PV实例类型提供PCID，以避免对性能造成最严重的影响。即使您选择HVM作为您的虚拟化类型，某些实例系列仍不会公开PCID功能，因此您也应该避免使用这些功能。

hs1(或“高存储”)实例类型可能最受影响;它是最常用的工作负载，需要大量的磁盘I/O系统调用，从而从崩溃补丁中带来最高的性能开销，并且它不支持PCID，这意味着您可能会受到两次影响。