问熔毁与幽灵-修补未修补的虚拟机管理程序的来宾内核是否防止跨VM内存泄漏？

EN

根据我对漏洞的了解，不--推测的缓存攻击绕过了CPU对进程从任意地址获取内存的所有保护。

我相信这将包括邻居‘m(甚至那些修补程序以防止攻击本身)以及虚拟机管理程序的内核内存空间--但是即使我遗漏了一些可以防止直接内存泄漏的东西，攻击者也有可能利用它们对内核内存的访问来获得对hypervisor的更完整的访问。

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

幽灵和熔毁。

我们从哪里开始？不好的，我的意思是非常糟糕的新闻稿，可能或可能不会影响您的计算机，工作站，服务器或服务器在云端。是的，完全是这样，但你必须在本地访问与CPU相关的CPU，这可能是一台PC或一部手机，苹果已经树立了一个榜样，但让我们想想它的ARM CPU，所以这是每个支持(特性/微码暴露/操作系统/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.html

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

我们的BSD朋友是怎么说的？

糟糕的谷歌;(

(对此进行Powershell检查;)

Linux内核好吧，我们度过了一个有趣的一周，到现在每个人都知道为什么我们要合并所有奇怪的x86页面表隔离补丁，而不遵循所有正常的发布时间规则.

我可能会回来编辑这篇文章。我相信这个不存在的问题(直到在野外)将不会是一个真正的问题。谷歌真该在这里跟踪信息披露的日期！-1代表谷歌