Anthropic Simon 测试了 smolvm，但沙箱仍需要控制平面

Anthropic 研究员 Simon Willison 围绕一项目标要求严苛的任务测试了 smolvm：在不允许网络、文件系统或资源滥用的前提下，安全执行不受信任的 Python 和 JavaScript。实验很快遇到冲突：网页版 Claude Code 运行在 Firecracker 来宾环境中，而 smolvm 需要访问该来宾环境未暴露的硬件虚拟化能力。

这一失败并不意味着 smolvm 不安全。它表明，在另一台受限虚拟机中评估 microVM，可能在安全测试尚未开始前就失败。对于正在考虑运行用户提供的脚本、AI 生成程序或自动化数据转换任务的团队而言，这一区别至关重要。

这份沙箱研究笔记还揭示了一个更大的工程缺口。强大的虚拟机边界只是安全代码执行服务的一部分。运营方仍需要在该边界之外提供截止时间、资源核算、文件准备、输出控制、监控和清理机制。

smolvm 提供了若干实用要素：默认禁用网络，每个工作负载拥有独立的来宾内核，并且 CPU 和内存均可配置。但这些功能并不会自动构成一项可用于运行恶意代码的生产服务。

因此，真正的较量并非 smolvm 对 Docker，或 Python 对 JavaScript，而是“一条命令实现隔离”的承诺，与可靠多用户执行所需运营控制能力之间的较量。

测试在不受信任的代码运行前就失败了

第一个结果是环境兼容性失败，而不是沙箱逃逸或资源限制失效。

Willison 请一个通过网页版 Claude Code 运行的 Anthropic 模型，研究 smolmachines 是否适合作为快速沙箱。计划中的工作负载很明确：运行用户提供的代码，以完成结构化数据转换等任务。

这些代码需要严格边界：不应看到网络，只能访问指定文件，消耗受限内存，并在运营方定义的时间间隔后停止。诸如 while true 的无限循环不应无限占用计算资源。

该模型能够研究项目并设计测试，但无法启动执行测试所需的 smolvm 虚拟机。根据 Willison 的描述，Claude Code 环境本身已是在 Linux 上运行的 Firecracker 来宾环境。

smolvm 通过特定平台的虚拟机监控程序使用硬件辅助虚拟化。在 Linux 上，这通常意味着 KVM，即向虚拟机监控程序暴露处理器虚拟化功能的内核接口。受限的云端来宾环境往往缺少启动另一台硬件加速来宾所需的 /dev/kvm 设备。

这就是嵌套虚拟化问题。只有外层平台暴露必要的处理器功能和设备访问权限时，一台虚拟机才能托管另一台虚拟机。许多托管式沙箱会刻意不提供这些能力。

这一限制造成了一个不同寻常的测试悖论。网页版 Claude Code 之所以受到隔离，部分原因正是它运行在 microVM 中；但这种隔离也阻止它启动被要求评估的另一层 microVM。

在此次尝试中，没有任何有意义的 Python 或 JavaScript 攻击工作负载真正运行到 smolvm。测试未产生关于启动延迟、内存强制限制、CPU 饱和、文件隔离或终止行为的独立测量结果。

这一缺失的证据应当影响所有结论。若声称该实验已验证 smolvm 是安全的执行服务，将并不准确；同样，把启动受阻视为针对 smolvm 来宾隔离能力的证据，也并不准确。

相反，结果识别出了一项部署前提：团队必须在兼容的物理主机上，或在允许嵌套虚拟化的虚拟机中运行 smolvm。

官方的 smolvm security model 将 KVM 列为 Linux 后端。它还分别支持 Apple 的 Hypervisor framework 和 Windows Hypervisor Platform。

这种跨平台设计有助于本地开发，但并不意味着 smolvm 可以在现有的每一种 agent 沙箱、持续集成 worker 或 serverless 环境中运行。

对于 anthropic simon 实验而言，这是第一个重要的反转：保护研究 agent 的同一隔离层，也阻止该 agent 测试第二层隔离机制。

Anthropic Simon 揭示了缺失的控制平面

smolvm 可以提供 VM 边界，但其外围应用必须决定代码何时启动、获得什么，以及何时被终止。

该项目将 smolvm 描述为用于隔离、可移植 Linux 虚拟机的命令行工具。每个工作负载都通过 libkrun 运行在独立的来宾内核中；libkrun 是专为轻量级工作负载设计的虚拟机监控程序。

这种架构提供了比普通容器更强的默认边界。传统容器通常共享主机内核，即便 namespace 隐藏了进程、网络和挂载点也是如此。smolvm 来宾则在 hypervisor 边界之后拥有独立内核。

这种差异减少了对主机内核的直接暴露，但并不意味着可以信任来宾内运行的一切。smolvm 文档明确表示，运营方应将来宾 root 视为不受信任。

其默认网络策略符合 Willison 的目标。网络访问采用显式启用机制，因此未启用网络选项启动的虚拟机不应获得常规的出站连接能力。当应用需要范围严格受限的出站访问时，也可以使用主机 allowlist。

文件系统暴露同样是显式的。只有当运营方挂载主机目录时，来宾才能看到这些目录。这使得数据转换任务可以采用临时准备目录模式。

执行服务可以将指定输入复制到临时目录，以只读方式挂载该目录，提供独立的可写输出位置，并在验证结果后丢弃两者。

不过，smolvm 文档中的一项限制很重要：其 volume 接口挂载的是目录，而非单个文件。因此，承诺仅允许访问“指定文件”的服务，必须构建一个只包含这些文件的隔离目录。

该服务还必须保护这一准备过程。它应拒绝符号链接、异常设备文件、意外权限，以及逃离目标目录的路径。VM 边界无法纠正粗心的主机端文件准备流程。

可通过 --mem 选项或 Smolfile 配置内存；Smolfile 是 smolvm 的声明式虚拟机配置。文档记载的默认值为 8 GiB，内存通过弹性 virtio balloon 呈现。

弹性分配可提升主机利用率，因为主机不会立即提交全部已配置内存。但这不应与面向多个恶意任务的准入控制混为一谈。

如果服务以乐观配置启动大量来宾环境，聚合需求仍可能压垮主机。调度器需要独立的容量模型，覆盖内存、虚拟 CPU、存储和并发虚拟机数量。

CPU 配置也有类似区别。分配一个虚拟 CPU 会限制来宾内的并行执行，但并不会自动保证程序只获得固定数量的 CPU 秒。

单线程无限循环可以永远消耗其被分配的虚拟 CPU。hypervisor 会将循环限制在边界内，但外部 supervisor 必须强制执行截止时间并终止虚拟机。

生产系统通常同时需要基于墙上时钟时间和资源的策略。墙上时钟超时可处理卡死、休眠进程和死锁程序；CPU 核算则可发现持续消耗计算资源却没有进展的工作负载。

supervisor 必须留在来宾之外。虚拟机内运行的代码不应控制计时器、终止信号或最终清理决策，否则工作负载可能尝试关闭自身的安全护栏。

这正是“不受信任代码沙箱”这一说法可能掩盖两种不同产品的原因：其一是隔离引擎，其二是安全调度和监管该引擎的控制平面。

anthropic simon 测试的目标是完整的产品行为，而 smolvm 的公开接口主要提供构建该产品所需的隔离引擎和底层配置。

MicroVM 改变的是边界，而不是威胁模型

硬件虚拟化能改善隔离能力，但每一项被刻意转发给来宾的能力都会成为攻击面的一部分。

smolvm 使用 libkrun VMM 启动轻量级虚拟机。来宾拥有自己的内核，而主机保留对虚拟硬件和暴露设备的控制权。

该设计回应了容器的一项核心问题。容器利用内核功能隔离工作负载，但恶意进程仍会通过允许的系统调用与同一主机内核交互。因此，内核漏洞可能威胁容器边界。

MicroVM 系统将该边界向外推移。恶意代码首先接触的是来宾内核和虚拟设备；要抵达主机，通常需要跨越虚拟机监控程序或 hypervisor 边界。

AWS 围绕类似原则开发了用于 serverless 工作负载的 Firecracker microVMs。Firecracker 将 KVM 虚拟化与刻意精简的设备模型结合，以限制不必要的硬件模拟。

smolvm 并非 Firecracker 的简单封装。其现有文档描述了涵盖 macOS、Linux 和 Windows 的 libkrun 后端。不过，两种方法都将每个工作负载置于独立的来宾内核之后。

当 AI 系统自主编写代码时，这种隔离具有现实意义。生成的代码可能包含意外的破坏性行为、依赖攻击、凭据探测，或从不受信任数据中复制而来的蓄意载荷。

即使不涉及 AI，数据转换功能也面临同样风险。用户可以提交会扫描文件系统、反复 fork、持续分配内存直至失败，或尝试建立出站连接的 Python 代码。

JavaScript 并不会天然更安全。在这些能力仍然可用时，Node.js 程序可以读取文件、启动子进程、打开 socket、加载原生扩展并耗尽内存。

仅依靠语言层面的限制往往很脆弱，因为标准库暴露了广泛功能。传递依赖也可能引入原生代码或意料之外的访问路径。

完整的 Linux 来宾环境让开发者可以运行普通的 Python 和 Node.js 软件包，而无需为专用运行时重写它们。这种兼容性正是 microVM 依然具有吸引力的原因之一。

代价是更大的来宾环境。服务必须提供内核、运行时镜像、库和虚拟设备。每个需要维护的组件都会影响补丁管理、可复现性和可信计算基。

smolvm 文档将主机操作系统、hypervisor 后端、libkrun、smolvm 以及调用方主机账户列为可信组件。这些层级中的任何一处遭到攻破，都可能削弱其承诺的边界。

文档还警告了显式能力转发的风险。挂载目录会暴露其中内容；启用网络会扩大可访问的服务范围；转发 SSH agent 会使来宾进程能够在 socket 可用期间请求签名。

这些功能对于开发机器而言是合理的。在运行匿名或对抗性提交的服务中，它们通常应保持禁用状态。

GPU 访问需要更加谨慎。smolvm 支持涉及共享主机 GPU 资源或主机端进程的接口。其文档称，不应将 CUDA 远程访问视为经过加固的多租户 GPU 隔离机制。

这一限制不会影响简单的 Python 数据转换任务。它体现了一条更广泛的原则：便利功能可能会跨越清晰的来宾边界，而正是这一边界让基础架构具备吸引力。

对于敌对工作负载，最安全的配置应当刻意保持朴素：不使用网络、不转发凭据、不提供主机服务、不使用 GPU，仅提供最少的只读输入，并设置可随时丢弃的输出区域。

每项任务完成后都应销毁虚拟机。复用机器可能会将被修改的文件、进程、缓存或隐藏状态带入下一位用户的执行环境。

可移植镜像有助于建立一致的运行时环境。smolvm 使用 OCI 镜像，并基于 OCI image format，因此运营方可以使用熟悉的打包标准准备 Python 或 Node.js 环境。

镜像兼容性并不等于镜像可信。生产服务仍需要固定摘要、受控镜像仓库、漏洞处理机制，以及在安全更新后重建运行时的流程。

资源限制不能只靠 CPU 和内存标志

最棘手的“while true”防线并非隔离，而是在所有故障模式下都能可靠终止。

内存设置会为来宾可见 RAM 设定上限。当程序超过这一容量时，来宾内核可以触发其内存不足处理机制。这能限制一种形式的资源滥用。

主机仍需观察接下来发生的情况。来宾可能只杀死一个进程、变得无响应，或花费大量时间回收内存。服务不能假定每次内存故障都会产生干净的结果。

严格的运行器应对结果进行分类。成功、用户异常、内存耗尽、超时、输出溢出、内部沙箱故障和主机容量拒绝，都是不同事件。

这种分类对用户和运营方都很重要。语法无效的转换脚本不应看起来像基础设施中断。启动失败的机器也不应消耗用户的重试额度。

CPU 限制需要多层措施。来宾可以获得受限的虚拟 CPU 数量。随后，诸如 cgroups 等主机控制机制可以相对于其他工作负载调节 VMM 进程。

截止时间监管器应在允许的时间间隔结束后终止整个 VM。仅杀死顶层 Python 或 Node.js 进程并不够，因为程序可以创建子进程或后台进程。

终止也必须具备升级机制。监管器可以先请求优雅关闭；如果来宾未响应，再停止 VMM 进程。它还应验证相关进程和临时资源均已消失。

输出也是一种资源。程序可能无限打印、创建巨大的结果文件，或生成深度嵌套的数据，在执行结束后耗尽解析器内存。

服务需要为标准输出、标准错误和生成文件设置字节限制。它应以流式方式处理或截断日志，而不是在应用内存中无限缓冲内容。

存储配额应覆盖来宾的可写层和每个导出的输出目录。否则，一个很小的输入就可能生成足以填满主机文件系统的数据。

进程数量同样重要。fork bomb 创建进程的速度可能快过人工操作员的反应速度。来宾内核需要进程限制，而主机也应约束 VMM 及其支持进程。

敌对程序也可以在不占满 CPU 的情况下消耗时间。它可能永久休眠、等待不存在的输入，或造成死锁。这正是墙钟时间截止机制仍不可或缺的原因。

时间应由外部控制平面测量。来宾可以修改自己的时钟，或干扰内部看门狗进程。主机的单调计时器提供了更可靠的来源。

文件导出只能在执行结束后进行。主机在将结果移入持久存储前，应检查文件类型、大小、路径和数量。

对于常见的数据转换，更严格的输出契约可以降低风险。运行器可以只接受一个 JSON 文档、一个 CSV 文件或一个有大小限制的归档文件，而不是任意目录树。

服务还应在启动机器前限制输入复杂度。压缩归档可能膨胀到远超上传大小，而恶意格式可能攻击来宾之外的解析器。

因此，安全流程从 smolvm 之前就开始：验证并暂存输入，创建全新的机器，施加运行时限制，停止机器，检查输出，然后销毁临时状态。

可观测性同样应置于来宾之外。运营方需要记录机器标识符、镜像摘要、启动和停止时间、退出分类、资源峰值以及清理状态。

这些记录默认应避免存储敏感用户数据。当脚本打印输入记录、凭据或专有内容时，日志可能成为另一条泄露通道。

这些要求并未削弱 smolvm 的价值。它们界定了将其底层原语转化为可靠服务所需的外围工作。

Docker、WebAssembly 和托管沙箱仍在竞争

smolvm 占据了一个有用的中间位置：它提供常规 Linux 兼容性，同时具备比共享内核容器更强的隔离。

对许多工程团队而言，Docker 仍是最容易的起点。镜像、镜像仓库、构建工具和编排系统已经支持大规模容器工作流。

容器可以应用命名空间、能力、seccomp 过滤器、只读文件系统和 cgroup 限制。当工作负载可信或风险仅属中等时，这些控制措施可能是合适的。

对于完全敌对的代码，共享内核仍是核心问题。主机内核或容器运行时中的逃逸漏洞，可能暴露其他工作负载和主机数据。

smolvm 通过为每台机器分配独立的来宾内核来改变这种暴露面。它还接受 OCI 镜像，降低了已有 Python 或 Node.js 环境团队的一部分迁移摩擦。

不过，容器平台拥有成熟的调度和策略层。smolvm 的安全文档指出，独立工具本身并不是经过加固的多用户控制平面。

将容器替换为 smolvm 的团队，必须避免在迁移过程中失去运行保障。更强的底层隔离配上更弱的调度器，仍可能产生不可靠的服务。

WebAssembly 走的是另一条路线。WebAssembly 运行时从受限的能力模型出发，然后明确授予文件或网络访问等功能。

这种方法可以为紧凑型转换工作负载创建更小的接口。它也支持快速启动，并能精确嵌入应用程序。

兼容性是其代价。标准 Python 和 Node.js 软件包可能依赖 Linux 系统调用、原生扩展、子进程，或受限 WebAssembly 环境中无法提供的运行时行为。

控制转换语言的团队或许可以接受这些限制。承诺广泛兼容 Python 和 JavaScript 的服务则会很快遇到它们。

托管代码沙箱提供了第三条路径。供应商将机器生命周期、超时、网络策略、存储和 API 打包为托管服务。

这可以缩短实现时间。但它也会将敏感代码和数据交给另一家运营方，引入服务依赖，并限制对底层隔离设计的控制。

自托管 smolvm 可让购买方自行管理运行时。同时，它也要求购买方负责主机加固、安全更新、容量规划、监控和事件响应。

选择应基于工作负载，而非潮流。受限表达式求值器不需要完整的 Linux 来宾。具有原生依赖的复杂 Python 软件包很可能需要。

对于一次性转换，microVM 启动时间相对于任务时长必须足够短。smolvm 表示，打包后的工作负载可在 200 毫秒内启动，但独立测量应覆盖购买方的具体主机和镜像。

基准测试应包括冷镜像获取、机器创建、运行时启动、输入暂存、执行、输出验证和销毁。只测量来宾启动时间会低估用户可见延迟。

团队还应测试密度。单个快速来宾对于评估一台主机在内存压力下同时运行数百个提交时的表现，说明不了太多。

因此，竞争问题比隔离强度更广泛。它还包括兼容性、启动行为、调度成熟度、运维负担，以及成功逃逸所造成的后果。

smolvm 值得评估，因为它将熟悉的 Linux 工作负载与 VM 边界结合在一起。anthropic simon 的尝试表明，这类评估必须在能够暴露所需虚拟化功能的基础设施上进行。

三项测试将决定 smolvm 是否已准备就绪

下一项有价值的证据必须来自敌对工作负载测试，而不是又一份功能清单。

第一个信号是在兼容的裸金属或嵌套虚拟化主机上进行可复现测试。它应通过同一个外部监管器运行 Python 和 JavaScript 测试套件。

这些套件应包括无限循环、内存耗尽、fork bomb、超大输出、文件系统探测、网络探测、延迟子进程和异常来宾关闭。每种情况都需要预期结果。

成功的结果将增强这样一种判断：smolvm 可以作为转换任务的隔离引擎。反复出现的清理失败或不一致的终止行为则会削弱这一判断。

第二个信号是明确、文档化的生命周期强制机制。参考运行器应展示如何施加墙钟时间截止、主机级 CPU 控制、内存上限、输出配额以及完整的机器销毁。

配置标志并不足够。测试应验证当来宾忽略关闭请求、填满存储空间并遗留后代进程时的行为。

这一信号将弥合 smolvm 的 VM 原语与 Willison 最初希望考察的服务之间的差距。缺少它，每个采用者都必须独立设计关键监管器。

第三个信号是在已声明威胁模型下进行安全审查。审查应识别受信任的主机组件、挂载文件行为、网络强制、镜像来源和多租户假设。

smolvm 的现有文档已经作出了一些有用披露。它表示，当前版本缺少签名和来源证明，但当其校验和文件可下载时，可以进行校验和验证。

这一披露为评估者提出了一个具体的供应链问题。生产运营方需要一套受控方法，用于获取、验证、固定和更新 smolvm 二进制文件及来宾镜像。

评估还应区分本地单用户执行与敌对多租户环境。在笔记本电脑上运行生成代码的开发者，与接受匿名提交的公共服务，面临的后果不同。

没有任何沙箱能把任意代码变成零风险工作负载。实际目标是分层遏制、受控能力、有界资源消耗，以及在某一层失效时快速恢复。

最有前景的部署模式，是将 smolvm 作为该系统中的一层。主机服务验证输入、创建可丢弃的来宾、禁止网络访问、强制执行截止时间、检查输出并销毁环境。

对于构建 AI 工作流的团队而言，这一教训不止关乎代码执行。任何允许模型操作本地信息的系统，都需要明确界定模型能够读取、写入和保留哪些内容。

一个可搜索的知识库可以帮助工程师留存测试结果、威胁模型和事件调查发现。它无法替代运行时隔离，但能让安全决策更易于审计。

因此，anthropic simon experiment 应被视为一项尚未完成的评估，但其首个发现具有参考价值。由于外层沙箱未提供虚拟化访问权限，smolvm 无法在所选的 Claude Code 环境中运行。

下一步不应放宽外层沙箱的限制，而应在专用的兼容主机上、借助外部监督器并配合公开的对抗性测试套件，重新进行这项评估。

当来宾环境变得恶意时，你的服务是否仍能停止每一项任务、仅保留已获批准的输出，并彻底完成清理？如果尚未对此进行测量，这个沙箱就还不能用于运行用户代码。