Qubes OS 把应用关进不同房间，却仍逃不开楼下的 Xen 和 CPU
韩启明｜OC 政策与安全编辑
韩启明｜OC 政策与安全编辑
根据预印本 Qubes OS Security in the Public Record，研究者分析了 2011 至 2025 年的 109 份 Qubes Security Bulletin 和官方 Xen 安全公告追踪数据。在主要分类方法下，87 份 Qubes 公告、即 79.8%，来自 Xen、CPU 微架构或其他上游组件，而不是 Qubes 自己的核心逻辑。
一句话结论： 这个结果不是证明 Qubes“不安全”，而是量化了隔离系统的现实：上层房间分得再细，共用的地基仍然决定所有房间能否真正隔开。
Qubes OS 的核心思想是 compartmentalization。工作、个人、银行和不可信文件放进不同虚拟机，剪贴板、网络和 USB 访问也被明确控制。一个浏览器被攻破后，攻击者不应该自然拿到其他安全域的数据。
这套架构依赖 Xen hypervisor 把不同虚拟机隔开，也依赖 CPU 正确实现内存和权限边界。于是 Qubes 自己的界面和管理代码写得再好，Xen 越界漏洞或 Spectre 一类微架构问题仍可能穿过最底层信任边界。
79.8% 说的不是入侵事故比例
论文分析的是公开安全公告归属，不是现实攻击，也不是潜伏漏洞总数。87/109 表示研究者把这些公告的主要原因归到上游组件；它不能解释有多少 Qubes 用户真的被攻破，更不能拿来计算“使用 Qubes 有 80% 概率因 Xen 中招”。
公开公告还会受到披露政策影响。一个项目越透明、越积极追踪上游，公告数量反而可能更高。没有公告不代表没有漏洞，频繁公告也不等于产品质量更差。
研究者检查的 464 份 Xen Security Advisory 中有 113 份影响 Qubes。季度公告序列在 2015 年第一季度出现明显变化，2018 年后的年度披露率大体保持平稳。论文因此把现状概括为“稳定，但不安静”：公告活动没有继续快速增长，却维持在早期更高的水平。
隔离还有意义吗
当然有。安全不是只有“绝对攻不破”和“完全没用”两个状态。大多数现实攻击发生在浏览器、文档解析器、扩展和用户应用层，Qubes 的分区能显著限制这些攻击横向移动。上游漏洞存在，说明隔离不是数学证明，不代表所有日常边界都失效。
这和容器、浏览器沙箱、云虚拟机面临的问题相同。多个不可信工作负载共享 kernel、hypervisor 或 CPU 后，底层组件成为高价值目标。架构师要做的是减少共用部分、及时更新、设计重启和迁移流程，并假定某一层最终可能出错。
Qubes 用户还面临一个很实际的取舍：频繁安装安全更新和重启会影响使用体验，但延迟更新又会让已公开的 Xen 或固件漏洞继续暴露。隔离系统的维护成本本来就是安全模型的一部分。
对 Agent 沙箱的直接提醒
今天很多 AI 产品宣称把代码 Agent 放进虚拟机或容器，因此可以放心执行陌生代码。Qubes 的数据提醒我们：沙箱只是把风险压到更小区域，hypervisor、共享目录、网络代理、宿主凭据和 CPU 都仍是信任锚点。
Agent 并发量增加后，底层逃逸漏洞的价值还会更高。企业不仅要问“有没有沙箱”，还要问沙箱共用什么、补丁多久部署、工作负载销毁后是否留下数据，以及控制平面被攻破会发生什么。
关键事实
- 研究分析的是 109 份公开 Qubes 安全公告，不是全部潜在漏洞或真实入侵事件。
- 79.8% 的公告被主要归因于 Xen、CPU/微架构或其他上游组件。
- 464 份 Xen 公告中有 113 份被官方追踪为影响 Qubes。
- 论文认为 2018 年后披露率大致稳定，但仍高于项目早期。
OC 判断
Qubes 的上游依赖不是架构失败，而是架构诚实面对的代价。真正值得怀疑的反而是把“运行在沙箱里”当作安全结论的产品宣传。隔离能缩小爆炸半径，但共享底层必须被列进威胁模型，并有持续更新和事故响应能力。
为什么重要
- 对开发者： 依赖图里最底层的组件往往拥有最大的跨边界影响力。
- 对企业： 使用虚拟机或容器不能结束安全评估，还需审查 hypervisor、宿主和控制面。
- 对用户： Qubes 仍能降低应用层攻击扩散，但需要及时更新，不能把它当成免维护保险箱。
评论
围绕这篇文章补充信息、提出问题或分享观察。