Agent 跑在什么环境里这件事在过去一年被反复讨论。早期大家图省事直接拿容器当沙箱一个 namespace 加几层 cgroup 就上线了。等到真正把能执行任意代码、能读写文件、能发起网络请求的 Agent 放进去才发现容器那层隔离在恶意代码主动逃逸面前基本是纸糊的——共享内核意味着一个内核漏洞就是全线失守。于是越来越多团队把目光转向 microVM而 Firecracker 几乎是这个方向上绕不开的选项。这篇就围绕 Agent Sandbox 里 Firecracker 的运行路径和安全边界展开把从 KVM 到 guest 内核、从 jailer 到 seccomp 的整条链路拆开讲清楚顺带把实际落地时那些文档里不会写的坑一并交代。适合正在给 Agent 设计执行沙箱、或者已经在用 Firecracker 但对其安全边界心里没底的同行参考。1. 为什么 Agent 场景非要把容器换成 microVM1.1 容器隔离在 Agent 场景下的真实短板先把话说直白容器不是不安全是它的安全模型和 Agent 的需求不匹配。容器依赖的是 Linux 内核提供的 namespace隔离视图和 cgroup限制资源再加上 capabilities、seccomp、LSM 这些机制做加固。问题在于所有这些机制都建立在大家共享同一个内核这个前提上。Agent 执行的是模型生成的、不可信、且往往带有试探性的代码——它可能故意去触发内核的边界条件也可能无意间踩到某个未修复的漏洞。一旦 guest 侧成功利用内核漏洞完成提权它面对的就是宿主机内核逃逸路径直接打通。我见过不少团队的做法是容器 gVisor。gVisor 确实把系统调用拦截在用户态重新实现了一遍隔离性比纯容器好很多。但它的代价是 syscall 兼容性和性能损耗某些 Agent 需要跑的东西比如依赖特定 ioctl、依赖 /proc 特殊字段、依赖某些内核特性的工具链在 gVisor 下会直接跑不起来或者行为诡异。这时候 microVM 的优势就体现出来了每个沙箱一个独立 guest 内核攻击面从共享内核收缩到虚拟化边界 精简 guest 内核。1.2 microVM 相比传统虚拟机的取舍传统虚拟机QEMU 全功能版也能做到内核隔离为什么不用因为太重。一个完整 QEMU 实例启动动辄几百毫秒到数秒内存开销上百 MB设备模型庞大到本身就是巨大的攻击面。Agent Sandbox 的特点是高频创建、短生命周期、按需销毁——一次任务可能只跑几秒到几分钟如果每次冷启动都要等一秒以上吞吐直接崩掉。Firecracker 的设计目标就是砍掉这些冗余它只保留 virtio 系列的精简设备模型virtio-net、virtio-block、virtio-vsock 等去掉 BIOS、去掉 PCI 枚举的大部分复杂度直接用 KVM 跑一个极简的 VMM。官方给出的数据是启动可以压到 125ms 以内、单实例内存开销几 MB 级别。这个量级才撑得起每个 Agent 任务一个 microVM的密度。1.3 Agent Sandbox 对隔离粒度的实际要求这里要区分两种隔离诉求。第一种是防误伤Agent 代码本身没恶意但可能因为 bug 把宿主机资源吃满、把文件写坏。这种用 cgroup 只读挂载就能解决容器够用。第二种是防对抗Agent 可能被 prompt injection 诱导或者用户就是故意让它执行危险代码。这种必须假设 guest 内部已经完全沦陷安全边界要落在 guest 之外。Agent Sandbox 的麻烦在于你没法提前判断这次任务是第一种还是第二种。所以工程上的稳妥做法是默认按防对抗设计把每个任务都当成潜在恶意来隔离。这就是为什么 microVM 从可选优化变成了默认基线。2. Firecracker 从 KVM 到 guest 的完整运行路径2.1 KVM 这一层到底做了什么Firecracker 本身不是 hypervisor它是个 VMM虚拟机监视器真正干活的是 KVM。KVM 是内核里的一个模块它把 Linux 内核变成一个 Type-2 hypervisor。Firecracker 通过/dev/kvm这个字符设备跟 KVM 交互核心就是两类操作KVM_CREATE_VM创建一个 VM 对象KVM_CREATE_VCPU创建虚拟 CPU然后用KVM_RUN这个 ioctl 让 vCPU 真正跑起来。KVM_RUN的语义很关键它会让当前线程进入 guest 模式直到发生VM Exit才返回用户态。VM Exit 的原因五花八门——guest 执行了特权指令、访问了未映射的内存、触发了 I/O、收到了中断等等。每次 exitFirecracker 都要判断原因并处理处理完再调KVM_RUN回到 guest。所以 Firecracker 的性能很大程度上取决于 exit 的频率和每次 exit 的处理开销。这也是为什么它要拼命精简设备模型设备越少能触发 exit 的路径越少。排查 KVM 是否可用最直接的就是看设备节点和权限ls -l /dev/kvm # 正常应该是 crw-rw---- 1 root kvm ... # 确认当前用户是否在 kvm 组 groups # 确认内核模块加载情况 lsmod | grep kvm # Intel 平台通常是 kvm_intelAMD 平台是 kvm_amd如果/dev/kvm不存在多半是宿主环境本身就在虚拟化里且没开嵌套虚拟化或者内核模块没加载。kvm-ok这个工具来自 cpu-checker 包能快速判断但很多精简镜像里没有直接看/proc/cpuinfo里的vmxIntel或svmAMD标志也行。2.2 Firecracker 进程启动时的资源准备顺序Firecracker 启动一个 microVM 不是一步到位的它有一套明确的配置顺序顺序错了会直接报错。典型流程是这样的进程启动读取配置命令行参数或通过 API socket 下发。配置 guest 内存指定内存大小Firecracker 通过mmap分配一块匿名内存作为 guest 物理内存。配置 CPU指定 vCPU 数量每个 vCPU 对应一个线程。加载内核镜像把 guest kernel 的 ELF/PE 镜像加载到内存指定偏移。配置 rootfs通过 virtio-block 挂载块设备或者用 initrd。配置网络virtio-net通常配合 tap 设备。配置 vsock用于宿主机和 guest 之间的高效通信Agent Sandbox 里这个特别有用。启动调用KVM_RUNguest 开始执行。这里有个容易踩的坑Firecracker 的配置 API 是一次性的很多配置项在实例启动后就不能改了。比如内存大小、vCPU 数量启动后再想调整只能重建实例。所以如果你的 Agent Sandbox 需要动态调整资源得在创建阶段就把规格算准或者干脆按规格池化预创建。2.3 guest 内核启动到 Agent 进程接管guest 内核启动后会走标准的 Linux 启动流程解压内核、初始化内存管理、挂载 rootfs、执行 init。在 Agent Sandbox 里这个 init 通常不是 systemd 那种重量级的东西而是一个极简的 init 脚本或者直接就是 Agent 的运行时进程。我推荐的做法是guest 里跑一个轻量的 init比如自己写的几十行 C 程序或者用 tini 这类它的职责就三件事——挂载必要的文件系统/proc、/sys、/dev、设置网络、拉起 Agent 执行器。Agent 执行器从 vsock 或者串口接收任务执行完把结果回传然后整个 microVM 就可以销毁了。这里的关键设计是guest 里不要有持久化状态。rootfs 最好是只读的需要写的地方挂 tmpfs。这样每次任务都是干净环境既避免了任务间的状态污染也让销毁变得毫无负担——直接杀进程内存回收完事。2.4 一次完整任务的生命周期时序把上面这些串起来一个 Agent 任务的完整生命周期大致是调度器收到任务从预热池里取一个已启动的 microVM或者冷启动一个。通过 vsock 把任务代码和输入传给 guest 内的执行器。执行器在 guest 内运行代码收集 stdout/stderr/退出码。执行器把结果通过 vsock 回传。宿主机侧收到结果触发 microVM 销毁。销毁时释放内存、关闭 tap 设备、回收进程资源。整个链路里宿主机和 guest 的唯一数据通道就是 vsock或者串口这个通道本身也是安全边界的一部分——它必须是单向可控的不能让 guest 通过它反向操作宿主机。3. Firecracker 的安全边界究竟划在哪里3.1 jailer 才是真正的隔离执行者很多人以为 Firecracker 的安全靠的是 Firecracker 本身其实不是。Firecracker 官方配套了一个叫jailer的工具它才是把 Firecracker 进程关进笼子的关键。jailer 做的事情包括创建新的 mount namespace、PID namespace、network namespace 等把 Firecracker 进程隔离起来。通过 chroot 把进程的根目录切到一个空目录让它看不到宿主机的文件系统。设置 cgroup 限制 CPU 和内存。丢弃所有不必要的 capabilities只保留运行必需的那几个。切换到非 root 用户运行。应用 seccomp 过滤器限制可用的系统调用。换句话说Firecracker 进程本身是被 jailer 用一整套 Linux 隔离机制包裹起来的。即使 Firecracker 的 VMM 代码存在漏洞被 guest 利用攻击者拿到的也只是 jailer 划定的那个受限环境而不是宿主机。3.2 seccomp 过滤器如何收窄系统调用面seccomp 是这条防线里最硬的一环。Firecracker 默认会加载一个白名单式的 seccomp 过滤器只允许它真正需要的系统调用通过其他一律返回错误或者直接杀掉进程。这个白名单非常窄大致包括内存管理mmap、munmap、mprotect、brk线程与同步clone、futex、sched_yieldI/Oread、write、ioctl且 ioctl 的请求码也受限信号rt_sigaction、rt_sigprocmask、sigaltstack时间clock_gettime进程控制exit、exit_group、gettid注意这里没有open、没有execve、没有socket网络是通过预先打开的 fd 操作的。这意味着即使攻击者控制了 Firecracker 进程他能做的事情也被死死限制住了——连打开一个新文件都做不到。实际部署时我建议用 Firecracker 自带的 seccomp 过滤器不要自己写。自己写很容易漏掉某个必要的 syscall 导致实例起不来或者为了让它跑起来把白名单放得太宽反而削弱了防护。如果确实需要调整用--seccomp-filter指定自定义过滤器但一定要在测试环境充分验证。3.3 设备模型精简带来的攻击面收缩前面提过 Firecracker 只保留 virtio 设备这里展开说为什么这很重要。传统 QEMU 支持几十种设备模型——IDE、SCSI、USB、VGA、声卡、各种网卡……每一种设备模型都是一大坨代码每一坨代码都是潜在的攻击面。攻击者可以通过 guest 向设备发送畸形数据来触发宿主机侧的漏洞。Firecracker 把设备砍到只剩 virtio-net、virtio-block、virtio-vsock、串口这几个而且每个都做了精简实现。攻击面从几十种设备收缩到几种设备而且这几种设备的实现代码量也小得多审计起来现实得多。这是减少攻击面这个安全原则的教科书级应用。3.4 边界之外的信任假设必须明确一点Firecracker 的安全边界假设guest 内部是完全不可信的。也就是说guest 内核可能被攻破guest 里的 Agent 代码可能是恶意的这些都在设计预期之内。安全边界要保证的是即使 guest 完全沦陷也无法突破到宿主机。但反过来宿主机侧的管理组件调度器、vsock 通信服务、镜像管理是受信任的。这个信任假设很重要因为它决定了你把防护资源投在哪里。如果你的调度器本身有漏洞能被 guest 影响那再强的 microVM 隔离也白搭。所以宿主机侧处理 guest 数据的代码要格外小心——所有来自 guest 的输入都当成不可信数据处理长度校验、类型校验、边界检查一个都不能少。4. 落地 Agent Sandbox 时的实操细节与坑4.1 镜像与内核的精简策略guest 内核不要用发行版默认的通用内核那个太大了启动慢、攻击面也大。应该自己编译一个最小内核只保留 Agent 运行必需的东西必要的文件系统ext4 或 squashfsrootfs、tmpfs、proc、sysfs网络virtio-net 驱动、TCP/IP 栈如果 Agent 需要联网vsockCONFIG_VIRTIO_VSOCKETS不要的东西所有物理设备驱动、所有不用的文件系统、所有调试选项、模块加载支持直接编译进内核或用 initramfsrootfs 同理用 Alpine 或者自己用 busybox 搭一个把 Agent 运行时Python/Node/Go 等装进去其他一律不要。镜像越小加载越快攻击面越小。我实测过一个精简到极致的组合内核 4MB 左右rootfs 20MB 左右冷启动能压到 150ms 上下。对比发行版默认内核动辄几十 MB差距非常明显。4.2 网络配置tap 设备与 NAT 的取舍Agent 需要联网时Firecracker 通过 virtio-net 对接宿主机的 tap 设备。配置流程大致是# 创建 tap 设备 ip tuntap add dev tap0 mode tap # 配置 IP ip addr add 172.16.0.1/30 dev tap0 # 启用 ip link set tap0 up # 开启转发 sysctl -w net.ipv4.ip_forward1 # 配置 NAT假设出口是 eth0 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE这里有几个坑。第一tap 设备是宿主机上的网络接口如果多个 microVM 共用需要做好隔离否则一个 guest 能嗅探到另一个 guest 的流量。稳妥做法是每个 microVM 一个独立 tap配合独立的网段。第二NAT 规则要限制源地址只允许对应网段出去避免被滥用。第三如果 Agent 根本不需要外网就别配网络直接省掉这一整块攻击面——很多 Agent 任务其实只需要访问内部服务用 vsock 就够了。4.3 vsock 通信的正确用法vsock 是宿主机和 guest 之间的高效通信通道不走网络栈性能好且天然隔离。Firecracker 支持 virtio-vsock宿主机侧通过 AF_VSOCK socket 连接 guest 的指定端口。用 vsock 有几个注意点guest 侧要监听在正确的 CID 和端口上。CID 是 Firecracker 分配的 guest 标识端口自己定。宿主机侧连接时用VMADDR_CID_HOST或者具体的 guest CID。vsock 的数据要当成不可信输入处理做长度限制。我见过因为没限制消息长度导致宿主机侧内存被打爆的案例。通信协议要设计成请求-响应式避免 guest 主动推送大量数据。4.4 资源限制与超时控制microVM 虽然隔离好但资源还是要限制。Firecracker 层面可以限制 vCPU 数量和内存大小但 CPU 的实际使用率、磁盘 I/O、网络带宽这些要靠 cgroup 和 tc 来管。超时控制是 Agent Sandbox 的刚需。Agent 任务可能因为死循环、等待外部资源等原因卡住必须有硬超时。我的做法是双层超时guest 内部执行器有一个软超时比如任务预期时间的 1.5 倍到点自己退出宿主机侧有一个硬超时比如软超时 30 秒到点直接杀 microVM 进程。软超时给任务一个优雅退出的机会硬超时兜底防止资源泄漏。4.5 常见故障的排查链路实际运维中遇到问题按这个顺序排查效率最高现象优先排查常见原因microVM 起不来/dev/kvm权限、内核镜像路径权限不足、镜像格式不对启动后立即退出Firecracker 日志、guest 内核日志内核 panic、rootfs 挂载失败网络不通tap 设备状态、iptables 规则tap 没 up、NAT 规则缺失vsock 连不上guest 侧监听状态、CID 配置端口没监听、CID 不匹配性能异常VM Exit 频率、cgroup 限制设备配置不当、资源被限排查时养成看日志的习惯。Firecracker 的日志通过--log-path指定guest 内核日志通过串口输出这两个是定位问题的第一手资料。很多莫名其妙的问题日志里其实写得清清楚楚。5. 把安全边界当成持续验证的对象5.1 边界不是配一次就完事安全边界这东西配置好只是起点。内核会更新、Firecracker 会发新版、Agent 的负载特征会变化任何一个变量变了边界都可能出现新的缝隙。所以要把边界验证做成常态化的东西而不是上线前跑一次就束之高阁。具体做法上我建议至少做三件事。第一定期用已知的逃逸测试用例比如针对 virtio 设备的畸形输入、针对 seccomp 的绕过尝试跑一遍确认防护仍然有效。第二跟踪 Firecracker 和 guest 内核的安全公告有相关 CVE 及时评估影响。第三对宿主机侧处理 guest 数据的代码做定期的模糊测试这块是最容易被忽视的薄弱环节。5.2 监控哪些指标能提前发现异常Agent Sandbox 的监控不能只看活没活着要看行为特征。几个值得盯的指标VM Exit 频率异常升高可能意味着 guest 在做某些不寻常的操作比如大量 I/O 或者反复触发特权指令。guest 内存使用曲线正常任务的内存曲线是平稳的如果出现持续增长可能是内存泄漏或者攻击尝试。vsock 消息大小分布如果突然出现大量超大消息可能是攻击者在试探宿主机侧的处理逻辑。microVM 生命周期分布如果大量实例异常短命秒级退出可能是启动失败或者被主动 kill。这些指标单独看可能说明不了什么但组合起来能勾勒出异常行为的轮廓。我的经验是把正常任务的这些指标基线摸清楚异常就很容易被识别出来。5.3 从能跑到敢跑的心态转变最后说点务实的。很多团队做 Agent Sandbox第一阶段的目标是能跑起来这时候关注的是功能。但真正要上线给用户用目标得变成敢跑——敢让不可信的代码在里面执行敢承担它可能带来的风险。这个转变的核心是把安全边界从事后补丁变成设计前提。Firecracker 提供的这套机制KVM 隔离、jailer、seccomp、精简设备模型本身是成熟的难的是把它们正确地组合起来并且在长期运维中保持住。我个人的体会是与其追求一个绝对安全的方案不如建立一个边界清晰、可验证、可演进的体系——知道边界在哪知道怎么验证它还在知道出问题时怎么收窄它。这才是 Agent Sandbox 能长期跑下去的基础。
