高度定制和打补丁的虚拟机管理程序、围绕所述虚拟机管理程序的沙箱以减少突破和大量监控。当然，任何给定的服务器只能托管这么多的虚拟机，因此如果能够通过管理程序之外的保护，突破基本上仅限于有限数量的来宾。例如，QEMU 可以使用强化工具链进行编译，使用 chroots、模式 2 seccomp、强制访问控制进行隔离。它可以通过使用自定义 seccomp 过滤器、禁用多余代码或功能、添加自定义、强化驱动程序来修补以使其更安全。可以配置和强化自定义内核，以限制逃逸来宾破坏内核和逃逸强制访问控制的能力。

不幸的是，这个问题的答案部分可以用“他们没有”来回答。许多云提供商确实经常受到损害，他们只是不知道或不披露。我看到这种情况周期性地发生，它并不漂亮。有时会使用 0days，有时会利用供应商鲜为人知的公共问题。例如，亚马逊的高端 dedis 在切换客户时不会关闭，导致他们的 GPU 不会擦除 VRAM，让下一个客户看到前一个客户在做什么（窃取 OpenCL 中的机密，通过 VNC 或使用 X11 转发发送的任何内容，等等）。亚马逊安全团队知道这一点，但仍未修复它。他们不会告诉他们的客户这一点。这表明在安全方面缺乏努力，以及对现有安全问题缺乏认识。如果您认为这样的事情会成为鲜为人知的重大新闻，那么针对云提供商的大规模或高级攻击可能会在公众不知情的情况下发生也就不足为奇了。缺乏攻击意识和新闻导致人们想知道这些大型企业到底是如何保持安全的。他们不是。

我的左边是一个打开 vim 的窗口。其中是最近用于突破某个中型云提供商的管理程序的 0day 代码。没有任何保护措施。所发生的只是漏洞利用爆发并获得了对具有管理程序运行进程的特权的主机的访问权限。没有沙箱或广泛的监控解决方案。导致内核漏洞的单个过时系统调用会导致内核受损和内存持久性（grsecurity 会减轻它，fwiw），以及随后的信息泄露。这家公司价值数亿美元。我敢肯定，无数人曾经去过那里。虽然这不是真实的证据，只是我自己的经验，

针对 vm 逃逸攻击的主要防御具体是深度防御。具体来说，如果存在各种丰富的防御机制，攻击者将触发足够多的防御机制，防御者可以阻止坏事的发生。即使攻击者成功突破了一个虚拟机管理程序中的一个虚拟机，仍然有一些东西可以捕获它们（例如Tripwire、防病毒、Modsecurity）。创建足够多的不共享漏洞的层，并且即使不是不可能也很难突破。

不过，在很多方面，你的问题都一针见血。一个熟练且积极主动的攻击者，能够构建针对所有防御的独特攻击，可以植入一个hyper-visor rootkit，而主机永远不会知道。

一个好的防御者团队应该能够理解和使用各种工具/技巧来阻止攻击者。希望这足以让您开始正确的方向。