Agent Sandbox 安全隔离：Firecracker microVM 架构与实战

1. 从一次线上事故说起：为什么 Agent 需要独立沙箱

去年年底我们团队在做一个代码执行类 Agent 产品，用户输入一段 Python 脚本，Agent 在云端跑完把结果返回。上线第三天就出了事：一个用户提交了while True: os.fork()，整台 8 核 16G 的宿主机在十几秒内被 fork 炸弹打满，连带上面跑的其他十几个租户任务全部挂掉。事后复盘，根因很清楚——我们把不可信代码直接扔进了宿主机上的 Docker 容器，而 Docker 共享内核这个事实决定了，容器逃逸和资源耗尽这两件事，本质上只能靠 cgroup 和 seccomp 去"缓解"，没法从架构上"隔离"。

这次事故之后我们开始认真评估 microVM 方案，最终落到 Firecracker 上。这篇文章就把我们踩过的坑、Firecracker 的运行路径、以及 Agent Sandbox 的安全边界怎么划，完整讲一遍。如果你正在做 Agent 执行环境、在线判题、CI 沙箱、或者任何需要"跑不可信代码"的场景，这篇应该能帮你少走几个月弯路。

先说清楚 Firecracker 是什么：它是 AWS 开源的轻量级虚拟机监视器（VMM），用 Rust 写的，专门为 serverless 和容器类负载设计。它基于 KVM 做硬件虚拟化，每个 microVM 有自己独立的内核，启动时间可以压到 125ms 左右，内存开销大概 5MB 起步。跟 QEMU 比，它砍掉了大量用不上的设备模拟，只保留 virtio 系列的最小子集，所以攻击面小得多。Agent Sandbox 要的就是这个——每个用户任务一个独立内核，跑完即销毁，互不影响。

2. Firecracker 的整体架构与运行路径拆解

2.1 三层结构：KVM、VMM、Guest

理解 Firecracker 的运行路径，得先把它拆成三层来看。

最底层是KVM，Linux 内核自带的虚拟化模块。它负责把 CPU 的虚拟化指令（Intel VT-x / AMD-V）暴露给用户态程序，同时管理内存的二级页表（EPT/NPT）。Firecracker 本身不碰硬件，它通过/dev/kvm这个字符设备跟 KVM 打交道，用ioctl下发创建 vCPU、设置内存区域、注入中断这些命令。

中间层是Firecracker VMM，也就是那个 Rust 二进制。它做三件事：解析配置、创建 microVM、处理 virtio 设备请求。它不模拟显卡、不模拟网卡硬件、不模拟 USB，只提供 virtio-net、virtio-block、virtio-vsock 这几个设备。设备少意味着代码路径短，代码路径短意味着漏洞少。

最上层是Guest，也就是跑在 microVM 里的那个 Linux 内核加 rootfs。它看到的是一个标准的 virtio 设备环境，内核里加载 virtio 驱动就能用。Guest 完全不知道自己在虚拟机里，也不需要知道。

2.2 一次请求的完整生命周期

我拿我们线上的一次真实调用举例，把路径串起来。

用户提交代码后，调度器选一台宿主机，通过 Firecracker 的 API socket 发一个PUT /machine-config，指定 vCPU 数量、内存大小。然后PUT /boot-source指定内核镜像路径和启动参数，PUT /drives挂载 rootfs，PUT /network-interfaces配置网络。最后InstanceStart一按，microVM 开始跑。

Guest 内核启动后，init 进程拉起我们的 agent-runner，它从 vsock 或者串口读任务、执行、把结果写回去。执行完，宿主机侧直接kill掉 Firecracker 进程，microVM 连同它的内存、磁盘快照一起消失。

整个过程从 API 调用到任务开始执行，我们实测 P50 在 180ms 左右，P99 大概 400ms。这个数字对 Agent 场景是可以接受的——用户感知不到，但隔离强度是容器给不了的。

2.3 为什么是 virtio，而不是设备直通

有人会问，既然要性能，为什么不搞 PCI 直通（VFIO）？答案在 Agent Sandbox 的场景里很明确：直通意味着把物理设备暴露给不可信代码，攻击面直接爆炸。而且直通需要 IOMMU 支持，宿主机配置复杂，热迁移也做不了。

virtio 是一套半虚拟化协议，Guest 和 Host 通过共享内存环（virtqueue）通信，Host 侧由 Firecracker 处理请求。它不模拟真实硬件，所以没有那些历史遗留的寄存器兼容性问题。virtio 的驱动在 Linux 内核里是标准组件，稳定性和性能都经过大规模验证。对我们来说，virtio-net 提供网络、virtio-block 提供磁盘、virtio-vsock 提供 Host-Guest 通信通道，三件套足够覆盖 Agent 的所有需求。

3. 安全边界到底划在哪：四层防御模型

3.1 第一层：KVM 硬件隔离

这是最硬的一层。每个 microVM 有独立的地址空间，Guest 的代码跑在 ring 3（或者 ring 0 但被 KVM 拦截），它想访问宿主机内存，必须经过 EPT 页表映射。没映射的地址，硬件直接抛异常。这跟容器共享内核有本质区别——容器里的进程理论上可以通过内核漏洞提权到宿主机，而 microVM 要逃逸，得先攻破 Guest 内核，再攻破 KVM，再攻破 Firecracker，难度是指数级上升的。

我们做过一个测试：在 Guest 里跑一段恶意代码，尝试读写宿主机物理内存。结果是 KVM 直接触发EXIT_REASON_EPT_VIOLATION，Firecracker 收到退出原因后选择终止 microVM。整个过程宿主机侧没有任何异常。

3.2 第二层：Firecracker 的最小设备面

Firecracker 的代码量大概 5 万行 Rust，对比 QEMU 的百万行 C 代码，攻击面小了两个数量级。它默认不启用任何非必要设备，连 PCI 总线都是可选的。我们线上配置里，只开了 virtio-net、virtio-block、virtio-vsock 和串口（用于日志），其他全部关闭。

这里有个实操细节：Firecracker 的 API socket 默认是 Unix domain socket，权限要设成0600，只有调度器进程能访问。千万别图省事监听 TCP，那等于把 microVM 的管理接口暴露到网络上。

3.3 第三层：Guest 内核加固

microVM 里的内核也是攻击面。我们用的是自己裁剪的 5.10 LTS 内核，关掉了所有用不上的驱动和子系统，只保留 virtio、ext4、网络栈。启动参数里加了console=ttyS0、panic=1、reboot=k，意思是 panic 后立即重启（实际上我们配置成直接退出）。

Guest 里还要做一层 seccomp 和 cgroup。虽然 microVM 已经隔离了，但 Guest 内部如果跑多个任务，还是需要限制。我们的做法是每个 microVM 只跑一个任务，跑完就销毁，所以 Guest 内部不做复杂隔离，只用一个非 root 用户跑 agent-runner。

3.4 第四层：资源配额与生命周期

这层是防"资源耗尽"的。Firecracker 支持给每个 microVM 设置 vCPU 数量、内存上限、磁盘 IO 限速、网络限速。我们线上默认配置是 2 vCPU、512MB 内存、磁盘读写各 100MB/s、网络 50Mbps。超了会被 Firecracker 的 rate limiter 直接限流，不会影响宿主机上其他 microVM。

生命周期管理上，我们给每个 microVM 设了硬超时：任务执行超过 30 秒，宿主机侧直接 kill。这个超时是宿主机侧控制的，Guest 里的代码改不了，防止用户提交死循环。

4. 从零搭一个 Agent Sandbox：完整实操流程

4.1 环境准备与内核编译

宿主机要求：Linux 4.14+，支持 KVM，CPU 有 VT-x/AMD-V。检查命令：

ls /dev/kvm grep -E 'vmx|svm' /proc/cpuinfo

如果/dev/kvm不存在，说明 KVM 模块没加载或者 BIOS 里没开虚拟化。

内核镜像我们用的是 Firecracker 官方提供的vmlinux示例，但生产环境建议自己编译。编译配置里必须打开CONFIG_VIRTIO_MMIO、CONFIG_VIRTIO_BLK、CONFIG_VIRTIO_NET、CONFIG_VIRTIO_VSOCKETS。裁剪完的内核大概 2MB 左右。

rootfs 我们用 ext4 格式，里面放一个最小的 busybox 加我们的 agent-runner。制作流程：

dd if=/dev/zero of=rootfs.ext4 bs=1M count=128 mkfs.ext4 rootfs.ext4 mkdir /mnt/rootfs mount rootfs.ext4 /mnt/rootfs # 拷贝 busybox、agent-runner、必要的库 umount /mnt/rootfs

4.2 Firecracker 配置与启动

Firecracker 的配置通过 API 下发，我写成一个 shell 脚本方便复用：

API_SOCKET=/tmp/firecracker.sock rm -f $API_SOCKET firecracker --api-sock $API_SOCKET --no-api & # 配置机器 curl --unix-socket $API_SOCKET -X PUT 'http://localhost/machine-config' \ -H 'Content-Type: application/json' \ -d '{"vcpu_count": 2, "mem_size_mib": 512}' # 配置内核 curl --unix-socket $API_SOCKET -X PUT 'http://localhost/boot-source' \ -H 'Content-Type: application/json' \ -d '{"kernel_image_path": "./vmlinux", "boot_args": "console=ttyS0 panic=1"}' # 配置 rootfs curl --unix-socket $API_SOCKET -X PUT 'http://localhost/drives/rootfs' \ -H 'Content-Type: application/json' \ -d '{"drive_id": "rootfs", "path_on_host": "./rootfs.ext4", "is_root_device": true, "is_read_only": false}' # 启动 curl --unix-socket $API_SOCKET -X PUT 'http://localhost/actions' \ -H 'Content-Type: application/json' \ -d '{"action_type": "InstanceStart"}'

这里有个坑：is_read_only如果设成 true，Guest 里就没法写文件，很多任务会失败。但设成 false 又意味着 Guest 可以改 rootfs。我们的做法是每个任务用一份 rootfs 的 copy-on-write 副本，跑完直接删，这样既保证可写，又保证隔离。

4.3 网络配置：tap 设备与 NAT

Firecracker 的网络通过 tap 设备接入宿主机。创建 tap：

ip tuntap add dev tap0 mode tap ip addr add 172.16.0.1/30 dev tap0 ip link set tap0 up

然后在 Firecracker 配置里指定：

curl --unix-socket $API_SOCKET -X PUT 'http://localhost/network-interfaces/eth0' \ -H 'Content-Type: application/json' \ -d '{"iface_id": "eth0", "host_dev_name": "tap0", "guest_mac": "AA:FC:00:00:00:01"}'

Guest 里配172.16.0.2/30，网关172.16.0.1。宿主机上开 NAT 让 Guest 能出网：

iptables -t nat -A POSTROUTING -s 172.16.0.0/30 -o eth0 -j MASQUERADE

注意：生产环境一定要给每个 microVM 分配独立的 /30 网段，否则多个 microVM 之间会 IP 冲突。我们用一个 IP 池管理器来分配和回收。

4.4 任务下发与结果回收

Host 和 Guest 之间的通信我们走 vsock，比串口快，比网络简单。Guest 里 agent-runner 监听 vsock 端口，Host 侧用socat或者自己写的客户端连接。

# Host 侧连接 Guest 的 vsock socat - UNIX-CONNECT:/tmp/firecracker.sock

实际上 Firecracker 的 vsock 是通过 Unix socket 代理的，配置里指定uds_path，然后 Host 侧连这个 UDS 就能跟 Guest 通信。

任务格式我们用 JSON：{"code": "...", "timeout": 30, "language": "python"}。Guest 侧执行完把{"stdout": "...", "stderr": "...", "exit_code": 0}写回去。

5. 性能调优与踩坑实录

5.1 启动速度优化

Firecracker 官方说 125ms 启动，我们实测冷启动 180ms 左右。差距主要在 rootfs 挂载和 init 进程。优化手段有几个：

一是用snapshot。Firecracker 支持把运行中的 microVM 快照下来，下次直接从快照恢复，跳过内核启动。我们实测恢复时间能压到 30ms 以内。但快照有个问题：恢复出来的 microVM 内存状态是固定的，如果任务需要干净环境，得在恢复后做一次 reset。

二是精简 init。我们把 init 换成一个静态编译的 C 程序，只做三件事：挂载 /proc、启动 agent-runner、等待。比 systemd 快得多。

三是 rootfs 用内存盘。如果任务不需要持久化，直接把 rootfs 加载到 tmpfs，读写都在内存里，快且干净。

5.2 常见问题速查表

5.3 几个血泪教训

第一个坑：忘了关 API socket 的 TCP 监听。早期版本我们图方便让 Firecracker 监听 TCP，结果被扫描到，有人尝试调 API 改配置。后来全部改成 Unix socket 加权限控制。

第二个坑：rootfs 共享导致数据泄露。一开始多个 microVM 共用一份 rootfs，结果 A 任务写的临时文件被 B 任务读到了。改成每个任务独立副本后解决。

第三个坑：vsock 缓冲区溢出。任务输出特别大时（比如打印十万行日志），vsock 缓冲区会满，导致 Guest 侧阻塞。后来加了流控，Host 侧边读边落盘，不积压。

第四个坑：快照恢复后的时钟漂移。从快照恢复的 microVM，系统时钟还是快照时刻的，导致 TLS 握手失败。解决方法是恢复后立即用 vsock 同步一次时间。

6. 安全边界的再思考：哪些事 Firecracker 也防不住

Firecracker 很强，但不是银弹。有几类攻击它防不住，得靠其他手段。

侧信道攻击。Spectre、Meltdown 这类基于 CPU 推测执行的攻击，理论上可以跨 microVM 泄露数据。缓解手段是内核打补丁、关闭 SMT（超线程），但会损失性能。我们的选择是接受这个风险，因为 Agent 场景下用户数据敏感度没那么高，而且攻击成本极高。

Guest 内核漏洞。如果 Guest 内核有提权漏洞，攻击者可以在 Guest 内提权到 root。但这只是 Guest 的 root，要逃逸到宿主机还得再攻破 KVM 和 Firecracker。所以 Guest 内核要及时更新安全补丁。

资源耗尽型攻击。虽然 Firecracker 有限流，但如果攻击者用合法请求打满 CPU，还是会影响同宿主机上的其他 microVM。我们的做法是宿主机上限制同时运行的 microVM 数量，留出余量。

供应链攻击。如果 rootfs 里的 agent-runner 被篡改，那隔离就形同虚设。所以 rootfs 要签名校验，启动时验证哈希。

7. 写在最后：一些个人体会

搞了半年多 Agent Sandbox，最大的感受是：安全隔离没有银弹，只有层层设防。Firecracker 给了我们一个很强的底座，但真正让系统稳的，是那些看起来不起眼的细节——API socket 的权限、rootfs 的副本策略、宿主机侧的硬超时、vsock 的流控。

如果让我给刚入坑的人一个建议，那就是：先把威胁模型想清楚，再选技术。你的 Agent 跑的是完全不可信的用户代码，还是半可信的内部代码？前者必须上 microVM，后者容器加 seccomp 可能就够了。别为了技术而技术，Firecracker 的运维复杂度比 Docker 高一个量级，团队得有相应的人力储备。

另外，Firecracker 的社区很活跃，但文档相对简略，很多细节得看源码或者翻 issue。我建议先把官方的那几个示例跑通，再逐步改造成自己的形态。别一上来就搞快照、搞热迁移，那些是优化阶段的事，先把基本路径跑稳。

最后分享一个小技巧：调试 microVM 时，把串口输出重定向到文件，firecracker --api-sock ... 2>&1 | tee vm.log，这样 Guest 内核的启动日志、panic 信息都能看到，比盲猜快得多。