smolvm 1.8.3 的这次安全测试,数字看起来相当漂亮:离线镜像、无网络执行、CPU/RAM 限额、存储配额、只读输入挂载,全部按预期工作,冷启动 0.6-1.5 秒,热执行只要 50 毫秒。但真正值得记下来的不是这些数字,而是测试过程里那个意外——负责测试的 AI agent Claude Fable 5,自己所在的环境根本跑不起 smolvm。
这不是产品问题,是一层套一层的虚拟化撞上了硬墙。
沙箱测沙箱,先被自己的笼子困住
Claude Code for web 这个容器环境,本身就是一台 Firecracker guest。它没有 /dev/kvm,CPU 也没暴露虚拟化指令集,意味着无法嵌套虚拟化——想在这层VM里面再开一层microVM,硬件条件不允许。smolvm machine run 直接报错 "kvm not available"。
Fable 5 的应对很直接:临时在 GitHub Actions 的 ubuntu runner(那里有 /dev/kvm)上建了一条工作流,把真正的测试跑在那里,拿到结果后把工作流删掉。Simon Willison 称这是"锲而不舍地主动"。但换个角度看,这也意味着测试环境不是提前设计好的,是agent现场拼出来的,拼完就拆——可复现性和可审计性,打了折扣。
官方宣传的<200ms,和实测的1.5秒
smolvm 官方文档给出的冷启动指标是"under 200ms",Willison 实测的是 0.6-1.5 秒,差了好几倍。差距大概率出在测试口径上:官方数字针对预构建、预热过的负载,不计入 OCI 镜像拉取和依赖安装的开销,而实测跑的是完整流程。
这不是谁在说谎,只是"厂商跑分"和"用户真实体验"从来不是一回事——AWS Lambda 冷启动的宣传数字和实际生产表现之间,业内早就见惯了类似的落差。想拿 smolvm 做生产级沙箱,拿自己真实的工作负载重新测一遍冷启动,比看官方 benchmark 更靠得住。
另一个容易被忽略的点是"guest-enforced timeout"。原文说超时机制"工作正常",但 smolvm 官方文档写得很清楚:standalone 版本本身没有沙箱级的执行超时,timeout 字段是健康检查用途,真正的"防止 while true 死循环",需要用户自己在 supervisor 或 guest 命令层去强制执行。cloud API 才有原生的 timeoutSeconds 参数。也就是说,那句"工作正常",很可能是 Fable 5 自己在测试脚本里加了一层超时包装,而不是 smolvm 开箱自带的能力。这个区别,决定了普通开发者能不能直接拿来用,还是得自己再写一层防护。
smolvm 在安全谱系里排第几
microVM 沙箱这条路子,Firecracker 是标杆,靠独立 guest 内核加硬件虚拟化,比共享内核的 Docker/nsjail 隔离性强得多;gVisor 走的是另一条路,不依赖硬件虚拟化,用应用层内核拦截系统调用,适合本来就在 VM 里、没法嵌套的场景。smolvm 更像"开发者友好版的 Firecracker"——底层用 libkrun,能直接吃 OCI 镜像,跨平台体验更顺手,但它不是一个独立的安全新范式。
- 提醒.smolvm 官方 README 明确写了自己不是"加固过的多用户控制平台",CLI 和 VMM 以调用者权限运行,host 卷挂载、网络、端口转发这些都是主动授予给 VM 的能力,安全责任在使用者身上。
这句话对 Willison 最初设定的目标——"执行用户提供的任务,做数据转换"——是个实打实的限制。如果只是单一可信来源触发的数据转换任务,smolvm 现在的默认配置(本地 4vCPU/8GiB内存、20GiB存储盘)基本够用。但如果想做成面向多个互不信任用户的公开代码执行 API,单靠 smolvm 不够,还得在上面叠一层独立 UID/GID 隔离、去掉 host 挂载之类的额外加固——厂商自己已经把这条红线画出来了。
沙箱测得再干净,测试环境自己搭得再仓促,结论都得打个问号
嵌套虚拟化的限制不只卡在 Claude Code for web 一家。任何构建在托管 agent 环境之上、需要底层硬件虚拟化能力的基础设施工具,都可能撞上同一面墙。这对正在给 AI coding agent 选沙箱方案的团队是个实在的提醒:先问清楚自己的执行环境有没有 /dev/kvm,再谈选型。