崩溃和幽灵-修补未打补丁的虚拟机管理程序的来宾内核是否可以防止跨VM内存泄漏？

漏洞大规模发布后24小时，Rackspace对Spectre和Meltdown保持沉默。他们没有修补所有Xen虚拟机管理程序的计划。他们所有较新的平台服务器都是易受攻击的HVM服务器。较旧的PV服务器不容易受到攻击。

我已经更新了HVM guest虚拟机的Linux内核，但是Rackspace尚未更新其任何虚拟机管理程序。在未打补丁的管理程序上更新来宾内核会阻止“坏家伙” VM访问从打补丁的主机泄漏的内存吗？

根据我对漏洞的了解，没有-推测性缓存攻击绕过了CPU的所有保护措施，以防止进程从任意地址中抢夺内存。

我相信这将包括相邻的VM（甚至打补丁以保护自己免受攻击的VM）以及虚拟机监控程序的内核内存空间-但是即使我缺少某些可以防止直接内存泄露的东西，也有可能攻击者可以使用对内核内存的访问来获得对管理程序的更完整访问。

如果您不信任在虚拟机管理程序上运行的所有虚拟机，则绝对不要冒险在任何类型的未修补虚拟机管理程序上运行敏感的工作负载。

幽灵和崩溃。

我们从哪里开始？不好，我的意思是非常糟糕的新闻稿，可能会或可能不会影响您的计算机，工作站，服务器或云中的服务器。是的，完全是，但是您必须本地访问相关的CPU，看来它可能是PC或电话。Apple已经成为一个例子，但让我们考虑一下其ARM CPU，以便支持该功能的每个Mobile平台都可以使用。 /微码公开/从OS / etc / etc对CPU的控制过多）

该应用程序必须在设备的CPU上运行，因此我认为控制台访问或至少访问系统的远程用户输入设备访问...。

目前，利用这些漏洞的唯一已知方法是通过本地/直接访问CPU（一旦拥有SSH / VNC等，再次可以是远程的）

以下是我到目前为止找到的补丁。

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

现在，这必须是对当前问题的最佳回应

我们的BSD朋友怎么说？

谷歌不好;（

一个Powershell检查是否相同;）

Linux内核好了，我们度过了有趣的一周，并且现在每个人都知道为什么我们要合并所有那些奇怪的x86页表隔离补丁，而又不遵循所有正常发行时间规则的情况。

我可能会（或将再次）编辑这篇文章。我确信，非问题（直到野外）不会成为真正的问题。Google确实应该遵守此处的披露发布日期！-1（对于Google）