Trail of Bits：虚拟机隔离经受了怎样的挑战

研究者在 Debian 12、AMD Zen3 开发机上设置 QEMU/KVM 虚拟机，要求智能体完成逃逸并读取目标文件。智能体运行在虚拟机外，通过 SSH 进入目标环境；作者解释这样安排是为了让虚拟机卡死后仍能保留研究过程，并称最终利用可以检查是否绕过任务条件。它不是把整个智能体都封闭在虚拟机内的系统评测。

第一阶段尝试已披露的宿主机内核漏洞，约一小时后主机卡死。文章开头称有三次逃逸，但这一节明确说尝试没有顺利完成；作者认为继续修改可以成功，这是判断，不能替换成已经读取目标文件的结果。更新内核后，第二阶段利用 libslirp 网络依赖中的已知缺陷与未标记为安全问题的修复，作者报告实现了逃逸。

第三阶段重新构建较新的 QEMU 和依赖，智能体在约十二小时的调查中多次退回失败路线，最终据作者报告串联三个发现时尚未公开的漏洞及一个未传入发行版的修复缺口。这个阶段展示了持续调查能力，也提示只看“包管理器已更新”可能漏掉依赖与上游补丁的差异。

虚拟机需要虚拟设备、网络和宿主机软件配合。它们让环境可用，也构成需要维护的隔离边界。这里的实验还有具体条件：作者的宿主机关闭了部分内核缓解措施，若干路线未成功，最终结果来自单台机器上的配置和研究者自述。它不能直接推广成所有虚拟机、模型或供应商方案都已失效。

作者另外尝试 Firecracker 时，报告了宿主机卡死，但没有成功逃逸。这个比较支持继续研究较小攻击面与及时更新的组合，不能证明 Firecracker 永远安全。对于实际部署，报告提出的检查方向包括减少开放的网络与设备能力、限制凭据权限、保留日志、主动监测，以及为任务提供有时限的新环境。

本站据详细过程修正了“三次得手”的摘要，并保留原文和原有日期。正文图解分别标出各阶段结果与共享边界，帮助读者理解这份报告证明到哪里；这里没有独立复现实验，也没有把作者的预测计入成功次数。