企业官网建设流程全解析

1. 什么是 Agent Sandbox：Firecracker 运行路径与安全边界？

Agent Sandbox 这个词最近在基础设施和 AI 工程圈里频繁出现，但很多人一听到就下意识联想到“沙箱”“隔离”“容器”，其实它远比 Docker 或 Pod 的隔离层级更硬、更底层。它不是在操作系统之上做逻辑隔离，而是在硬件虚拟化层直接切出一块“物理可信域”——用 Firecracker 构建的 microVM，就是这个可信域的唯一载体。我去年在给一家金融级大模型推理平台做安全加固时，第一次把 Agent Sandbox 落地到生产环境，当时最深的体会是：它不解决“能不能跑”，而是回答“敢不敢让这段代码碰生产数据”。Firecracker 不是另一个轻量容器运行时，它是用 KVM 做刀、用 Linux 内核做砧板，一刀切出独立 CPU、内存、设备视图的微型虚拟机；它的运行路径不是从 systemd 启动、不是走 cgroup 调度，而是由 vCPU 直接加载 ELF 入口、由 virtio-balloon 控制内存伸缩、由 jailer 二进制强制绑定命名空间——整条路径上没有一个环节依赖宿主机的用户态服务。所谓“安全边界”，不是靠 iptables 规则或 SELinux 策略去围，而是靠 CPU 的 VMX 指令集、内存的 EPT 页表、IO 的 virtio 协议栈这三道硬件级闸门来锁。你写的 Agent 代码哪怕调用了 ptrace、openat("/proc/self/mem")、甚至尝试 mmap /dev/kmem，在 Firecracker microVM 里连内核符号都看不到，因为整个 guest kernel 是只读加载的，rootfs 是只读挂载的，/proc 和 /sys 是精简重映射的。这不是“尽量不让它干坏事”，而是“它根本没能力干坏事”。适合谁参考？如果你正在设计 LLM Agent 的执行引擎、构建多租户函数计算平台、或者需要让第三方插件在银行核心系统旁安全运行——那你不是在选一个技术方案，而是在划一条不可逾越的红线。这条红线，就是 Firecracker 的运行路径所定义的安全边界。

2. 整体架构设计与核心思路拆解

2.1 为什么必须用 Firecracker 而不是 QEMU/KVM 或容器？

这个问题我被问过至少二十次，每次我都先反问一句：“你的 Agent 会执行什么？”如果答案里有“动态加载.so”“fork 子进程”“读取 /proc/pid/status”“调用 ioctl”“修改 ulimit”，那容器立刻出局。QEMU/KVM 虽然能虚拟化，但默认配置下启动一个 VM 要 300MB 内存、2 秒冷启动、占用完整 PCI 总线——这对每秒要启停上百个 Agent 的场景是灾难。Firecracker 的设计哲学非常明确：只做一件事，且做到极致——用最小攻击面提供最强隔离。它砍掉了所有非必要的模拟设备：没有 VGA、没有 USB、没有 SATA 控制器，只保留 virtio-net、virtio-block、virtio-vsock 三个设备；它禁用所有可写寄存器，vCPU 初始化后禁止修改 MSR；它用 jailer 将每个 microVM 绑定到独立的 mount namespace、pid namespace、cgroup v2 path，并通过 seccomp-bpf 白名单限制 host syscall（实测仅开放 87 个 syscall，连 clone() 都被替换成 clone3() 并限定 flags）。我们做过对比测试：同样运行一个 Python Agent，Docker 容器启动耗时 120ms，内存常驻 45MB；Firecracker microVM 启动耗时 38ms，内存常驻 18MB，且 CPU cache miss 率低 42%——因为没有设备模拟层的 trap-exit 开销。更重要的是，当 Agent 主动尝试读取宿主机 /etc/shadow 时，容器里返回 Permission denied（靠 LSM 拦截），而 Firecracker 里直接触发 #PF 异常并被 vmm trap，guest kernel 根本收不到 page fault handler 调用——这是硬件级拦截，不是软件策略。所以选择 Firecracker 不是“为了轻量”，而是“为了确定性”。它的运行路径从 vmm_main() 开始，到 vcpu_run() 结束，中间不经过任何用户态中间件，每一步指令都在 KVM ioctl 的原子上下文中完成。这种确定性，才是 Agent Sandbox 的基石。

2.2 Agent Sandbox 的三层边界模型：硬件层、VMM 层、Guest 层

很多团队把 Agent Sandbox 简单理解为“跑在 Firecracker 里的容器”，结果上线后发现还是能逃逸。问题出在没理清边界责任的分层。我们落地时画了一张三层边界图，现在成了内部标准文档：

• 硬件层边界：由 CPU VMX 指令集和内存 EPT 页表强制实施。Firecracker 启动时，jailer 会调用 ioctl(KVM_CREATE_VM) 创建 VM fd，然后通过 KVM_SET_USER_MEMORY_REGION 设置 guest 物理内存范围，这个 range 在 EPT 中被标记为不可执行、不可写（除非显式设置）。关键点在于：guest OS 的 page table walk 完全在 EPT 上进行，宿主机的 CR3 寄存器对它完全不可见。我们曾故意在 guest kernel 中 patch 一段代码试图读取 CR3，结果触发 #GP(0)，因为 VMX 拦截了所有控制寄存器访问。这就是为什么 Firecracker 不需要 hypervisor 级别的 rootkit 检测——它根本不给你接触硬件寄存器的机会。

• VMM 层边界：由 Firecracker 的 jailer 和 vmm 二进制共同定义。jailer 负责创建干净的 namespace 环境：chroot 到空目录、drop capabilities（CAP_SYS_ADMIN, CAP_NET_ADMIN 全部丢弃）、bind mount 只读 rootfs、设置 cgroup v2 memory.max=128M。vmm 本身用 Rust 编写，无 GC、无异常处理、无动态分配——所有内存都在 startup 时 mmap 分配，之后全程使用 arena allocator。我们审计过 vmm 的 syscall trace：启动阶段调用 openat/read/mmap/mprotect，运行期只调用 ioctl(KVM_RUN) 和 writev（日志输出），其余 syscall 全被 seccomp 拦截。这意味着即使 vmm 二进制被篡改，它也无法执行网络连接或文件写入——它的能力被编译时就锁死了。

• Guest 层边界：由精简 guest kernel 和只读 rootfs 实现。我们不用官方 alpine image，而是自己编译 5.10 内核，关闭所有非必要模块（CONFIG_MODULE_UNLOAD=n, CONFIG_PROC_FS=n, CONFIG_SYSFS=n），只启用 virtio、ext4、overlayfs。rootfs 用 squashfs 打包，mount 时指定 ro,errors=remount-ro。最关键的是 init 进程：不是 systemd，不是 busybox init，而是我们写的 200 行 C 程序，功能只有三件事：setup virtio-net、execve("/agent", argv, envp)、waitpid() 后 exit。这个 init 没有 fork 能力（disable clone syscall）、没有信号处理（sigprocmask block all）、没有文件系统操作（openat 只允许 /dev/vda1）。Agent 进程在它下面启动，父子关系链只有两层，且父进程在 execve 后立即放弃所有权限。这样设计的结果是：Agent 即使拿到 root 权限，也无法提权——因为根本没有提权路径。

这三层边界不是叠加关系，而是嵌套咬合。硬件层确保 VMM 无法被绕过，VMM 层确保 Guest 无法污染宿主，Guest 层确保 Agent 无法突破自身环境。少一层，整个 Sandbox 就变成纸糊的。

2.3 运行路径的不可篡改性：从 binary 加载到 vCPU 执行的全链路验证

Firecracker 的运行路径之所以能成为安全边界的锚点，是因为它每一步都可验证、不可跳过、不可注入。我们把整个路径拆成六个原子阶段，每个阶段都有签名或哈希校验：

1. jailer 启动校验：jailer 二进制必须由 SHA256SUMS 文件签名，启动时读取 /etc/firecracker/jailer.sig，用预置公钥验证。我们要求 jailer 必须以 --uid=65534 --gid=65534 运行，且启动后立即 drop capability bounding set。

2. microVM 配置加载：config.json 通过 memfd_create() 创建匿名内存文件，writev() 写入后立即 fcntl(F_ADD_SEALS, F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE)，防止 runtime 修改。我们额外加了一步：用 libseccomp 对 config.json 的 JSON 解析器做 syscall 白名单，只允许 read/write/mmap/munmap，禁用 openat。

3. kernel 和 initrd 加载：vmlinux.bin 必须带内嵌 signature（用 openssl dgst -sha256 -sign key.pem），vmm 启动时调用 crypto/verify.c 验证。initrd.cgz 用 gzip -9 压缩后，再用 sha256sum 计算 hash，该 hash 存在 config.json 的 "initrd_path_hash" 字段，vmm 启动时校验。

4. guest 内存初始化：vmm 调用 KVM_SET_USER_MEMORY_REGION 时，传入的 userspace_addr 指向 mmap(MAP_ANONYMOUS|MAP_NORESERVE) 分配的内存，该内存页在 mmap 后立即 mlock() 锁住物理页，防止 swap。我们还加了 page-level checksum：对每个 2MB hugepage 计算 xxhash，存入 metadata ring buffer，runtime 可随时校验。

5. vCPU 初始化：KVM_CREATE_VCPU 创建 vCPU fd 后，vmm 调用 KVM_SET_REGS 设置初始寄存器状态，其中 RIP 必须指向 kernel entry point（0x1000000），RSP 指向预分配 stack，CR0.PG=1（开启分页），CR4.PCIDE=0（禁用 PCID）。这些值全部硬编码在 vmm 二进制中，无法通过 config.json 修改。

6. vCPU 执行循环：KVM_RUN ioctl 返回后，vmm 检查 exit_reason。合法 exit 只有三种：KVM_EXIT_IO（virtio 设备访问）、KVM_EXIT_MMIO（内存映射 IO）、KVM_EXIT_HYPERCALL（guest kernel 调用）。其他 exit_reason（如 KVM_EXIT_EXCEPTION）直接 kill vCPU。我们甚至 patch 了 vmm，在 KVM_RUN 前对 vCPU fd 执行 fcntl(F_SETFD, FD_CLOEXEC)，防止 fd 泄露。

这条路径上没有任何一个环节依赖外部配置或动态加载。jailer 的 uid/gid、kernel 的 signature、memory 的 mlock、vCPU 的寄存器初值——全部在 build time 固化。这意味着你部署的不是“一个 Firecracker 实例”，而是“一个可验证的硬件抽象实例”。当运维说“这个 Agent Sandbox 跑起来了”，他指的不是进程存在，而是这六步校验全部通过，且每一步的输入输出都可审计。

3. 核心细节解析与实操要点

3.1 jailer 的深度定制：不只是 namespace 隔离，更是能力裁剪

很多团队直接用 firecracker --jailer 启动，结果发现 jailer 进程仍有 CAP_SYS_CHROOT 能力，能 chroot 到任意路径。这是对 jailer 的最大误解——它不是“帮你建 sandbox”，而是“把你关进 sandbox”。我们做了三轮 jailer 定制：

第一轮：删减 capabilities。原始 jailer 编译时保留了 CAP_SYS_CHROOT、CAP_SYS_PTRACE、CAP_NET_BIND_SERVICE，我们认为这违背最小权限原则。我们修改 build.rs，将 cap-ng 库的 cap_set_proc() 调用改为只保留 CAP_CHOWN、CAP_FSETID、CAP_SETUID、CAP_SETGID，其余全部 drop。编译后用 capsh --print 验证，输出显示 “Current: =ep”（effective+permitted caps 为空），证明能力已清空。

第二轮：强化 namespace 绑定。默认 jailer 只创建 mount/pid/uts namespace，我们增加了 user namespace：在 jailer 启动时调用 unshare(CLONE_NEWUSER)，然后写 /proc/self/uid_map 和 /proc/self/gid_map，将 guest uid 0 映射到 host uid 65534。这样即使 Agent 在 guest 内执行 chown root:root /，host 上对应文件 owner 仍是 nobody:nogroup。我们还禁用了 /proc/sys/kernel/unprivileged_userns_clone，防止普通用户创建 user namespace。

第三轮：cgroup v2 精细控制。jailer 默认只设置 memory.max，我们扩展了 cpu.weight（设为 10）、pids.max（设为 32）、io.weight（设为 100）。最关键的是 io.max：我们为每个 microVM 分配独立 io.bfq.weight，避免 I/O 抢占。实测发现，当 50 个 microVM 同时读取块设备时，未设 io.max 的实例延迟抖动达 200ms，设了 io.max 后稳定在 8ms±2ms。jailer 启动时还会检查 cgroup v2 是否启用（读取 /proc/cgroups），若未启用则 panic，强制运维升级内核。

提示：jailer 的 --chroot-base-dir 参数必须指向一个空目录，且该目录 owner 必须是 jailer uid。我们用 ansible playbook 自动创建：mkdir -p /var/lib/firecracker && chown 65534:65534 /var/lib/firecracker && chmod 0755 /var/lib/firecracker。任何非空目录都会导致 jailer 启动失败——这是设计使然，不是 bug。

3.2 guest kernel 的裁剪与加固：去掉一切“可能被利用”的接口

官方 Firecracker 推荐用 4.14 kernel，但我们坚持用 5.10 并深度裁剪。裁剪不是为了省几 MB 内存，而是消除攻击面。我们维护了一个 .config diff 文件，重点改动如下：

• 禁用所有调试接口：CONFIG_DEBUG_KERNEL=n, CONFIG_KPROBES=n, CONFIG_FUNCTION_TRACER=n, CONFIG_STACK_TRACER=n。特别注意 CONFIG_PROC_KCORE=n —— 这个选项若开启，/proc/kcore 会暴露整个物理内存布局，是 VM escape 的黄金入口。

• 关闭危险文件系统：CONFIG_AFFS_FS=n, CONFIG_HFSPLUS_FS=n, CONFIG_NTFS_FS=n, CONFIG_UDF_FS=n。只保留 CONFIG_EXT4_FS=y 和 CONFIG_OVERLAY_FS=y。overlayfs 用于只读 rootfs + 可写 upperdir，upperdir 严格限制大小（mount option upperdir=/tmp/upper,size=16M）。

• virtio 设备最小化：CONFIG_VIRTIO_PCI=n（禁用传统 PCI 模拟），只启用 CONFIG_VIRTIO_MMIO=y（内存映射 IO）。CONFIG_VIRTIO_NET=y 但禁用 CONFIG_VIRTIO_NET_DEBUG=n；CONFIG_VIRTIO_BLK=y 但禁用 CONFIG_VIRTIO_BLK_SCSI=n。我们甚至 patch 了 virtio-blk 驱动，移除所有 bio_split 相关代码，因为 split 操作可能触发内存越界。

• 进程管理收紧：CONFIG_PROC_FS=n（彻底禁用 /proc），CONFIG_SYSFS=n（禁用 /sys），CONFIG_PROC_SYSCTL=n。init 进程通过 /dev/virtio-ports/org.firecracker.legacy.initctl 发送命令，而不是 sysctl。我们还禁用了 CONFIG_CHECKPOINT_RESTORE=n，防止 c/r 攻击。

编译后，我们用 size vmlinux 查看：原始 5.10 kernel vmlinux 为 12.8MB，裁剪后为 3.2MB，text 段减少 68%。但这不是终点——我们用 objdump -d vmlinux | grep "call.sys_" 统计系统调用入口，原始有 312 个 sys_符号，裁剪后只剩 47 个（主要是 read/write/open/close/ioctl）。这意味着 guest kernel 的 syscall 表被压缩到极致，Agent 即使拿到 kernel pointer，也找不到可用的 gadget。

注意：CONFIG_INITRAMFS_SOURCE 必须指向一个空目录。我们不用 initramfs，而是用 kernel command line 的 "rd.live.image rd.live.overlay" 参数直接挂载 squashfs。这样避免 initramfs 解压时的内存拷贝开销，且 squashfs 本身支持 transparent decompression，CPU 使用率降低 15%。

3.3 agent runtime 的沙箱化封装：不止是 execve，而是进程树重构

Agent 不是直接 execve 启动的，而是通过我们自研的 agent-runner 封装。这个二进制只有 12KB，用 Zig 编写（无 libc 依赖），核心逻辑三步：

1. 环境净化：调用 prctl(PR_SET_NO_NEW_PRIVS, 1) 禁止后续 setuid/setgid；调用 prctl(PR_SET_DUMPABLE, 0) 禁止 core dump；调用 close_range(3, ~0U, 0) 关闭所有非 stdio fd；调用 unshare(CLONE_NEWNS) 创建新 mount namespace 并 bind mount /dev/null over /proc。

2. 资源限制：调用 setrlimit(RLIMIT_CPU, {10,10}) 限制 CPU 时间 10s；调用 setrlimit(RLIMIT_AS, {134217728,134217728}) 限制地址空间 128MB；调用 setrlimit(RLIMIT_CORE, {0,0}) 禁用 core dump。最关键的是调用 prctl(PR_SET_CHILD_SUBREAPER, 0)，确保子进程不会被 init 接管——所有子进程必须由 agent-runner waitpid，否则直接 SIGKILL。

3. execve 封装：agent-runner 不直接 execve，而是 fork() 后在子进程中调用 pivot_root() 切换 rootfs（从 squashfs 切到 overlay upperdir），然后 execve。父进程 loop 调用 waitpid(-1, &status, WNOHANG)，一旦子进程退出，立即 umount overlay 并 exit。整个过程 agent-runner 的 /proc/self/status 显示 PPid=1（init），但实际 init 是 guest kernel 的 init，不是 host 的。

我们还加了一个 anti-debug 机制：agent-runner 启动时读取 /proc/self/status 的 TracerPid 字段，若不为 0 则 exit(1)。实测 strace -f ./agent-runner 会直接失败，因为 strace 依赖 ptrace attach，而 agent-runner 在 fork 前就禁用了 ptrace。

实操心得：agent-runner 必须静态链接，且 strip -s 删除所有 symbol。我们用 zig build-exe --static --strip agent-runner.zig 编译，生成的二进制用 file 命令检查显示 “statically linked”，用 ldd 检查显示 “not a dynamic executable”。这样即使 Agent 用 readelf -s 查看自身 binary，也看不到任何函数名，增加逆向难度。

4. 实操过程与核心环节实现

4.1 从零构建可验证 microVM 镜像：kernel/initrd/rootfs 三位一体打包

我们不用 docker build，而是用一套纯 shell 脚本流水线，确保每一步可审计、可复现。整个流程分为四个阶段：

Stage 1：kernel 编译与签名

# 下载 5.10.123 内核源码 wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.123.tar.xz tar -xf linux-5.10.123.tar.xz cd linux-5.10.123 # 应用我们的裁剪 config cp /path/to/firecracker-kernel.config .config make olddefconfig make -j$(nproc) bzImage # 生成内核 signature openssl dgst -sha256 -sign /etc/firecracker/kernel.key vmlinux > vmlinux.sig # 打包为 vmlinux.bin（包含 signature） cat vmlinux vmlinux.sig > vmlinux.bin

关键点：vmlinux.bin 不是 raw kernel，而是 kernel + signature 的拼接体。vmm 启动时读取前 8MB（kernel size），后 512B 为 signature，用 OpenSSL 验证。这样避免单独传输 signature 文件带来的完整性风险。

Stage 2：initrd 构建
我们不用 dracut，而是手写 initramfs 目录结构：

initramfs/ ├── init # 200 行 C 程序，功能极简 ├── bin/ │ └── sh # 静态链接 busybox，只含 echo/ls/cat └── lib/ └── modules/ # 仅 virtio.ko, ext4.ko, overlay.ko

构建命令：

find initramfs | cpio -o -H newc | gzip -9 > initrd.cgz sha256sum initrd.cgz > initrd.cgz.sha256

注意：initrd.cgz 必须用 gzip -9 压缩，因为 Firecracker 的 decompress 函数只支持 gzip，且要求 level 9（最高压缩比）才能保证 decompress 时间 < 5ms。

Stage 3：rootfs squashfs 打包

# 创建临时目录 mkdir -p rootfs/{bin,lib,etc} # 复制 agent-runner 和依赖库 cp /path/to/agent-runner rootfs/bin/ cp /usr/x86_64-linux-gnu/lib/libc.so.6 rootfs/lib/ # 生成只读 fstab echo "/dev/vda1 / ext4 ro,errors=remount-ro 0 1" > rootfs/etc/fstab # 打包 squashfs mksquashfs rootfs/ rootfs.sqsh -no-xattrs -no-fragments -comp xz -Xbcj x86 # 计算 hash 供 config.json 引用 sha256sum rootfs.sqsh > rootfs.sqsh.sha256

关键参数：-no-xattrs 禁用扩展属性（减少攻击面），-no-fragments 禁用碎片（提升随机读性能），-comp xz -Xbcj x86 使用 x86 优化的 BCJ filter，压缩率比 gzip 高 12%，且 decompress 速度更快。

Stage 4：config.json 生成与签名

{ "boot-source": { "kernel_image_path": "/path/to/vmlinux.bin", "initrd_path": "/path/to/initrd.cgz", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off iommu=off" }, "drives": [{ "drive_id": "rootfs", "path_on_host": "/path/to/rootfs.sqsh", "is_root_device": true, "is_read_only": true }], "network-interfaces": [{ "iface_id": "eth0", "host_dev_name": "veth0" }], "machine-config": { "vcpu_count": 2, "mem_size_mib": 128, "ht_enabled": false }, "initrd_path_hash": "sha256:abc123...", "rootfs_path_hash": "sha256:def456..." }

boot_args 中 pci=off 和 iommu=off 是关键：禁用 PCI 总线和 IOMMU，彻底切断设备直通可能。我们还加了 panic=1，确保 kernel panic 时立即 shutdown，不留下可疑状态。

整个流水线最后生成一个 manifest.json，包含所有文件的 sha256 和 build timestamp，供 CI/CD 审计。每次部署前，运维必须用 sha256sum -c manifest.json.verify 校验所有文件。

4.2 Firecracker vmm 的 patch 与编译：注入边界校验逻辑

官方 Firecracker vmm 二进制不满足我们的审计要求，我们基于 v1.5.0 源码做了四类 patch：

Patch 1：syscall 白名单强化
在 src/vmm/src/vmm.rs 的 Vmm::run() 函数中，我们插入 seccomp 规则：

let mut builder = SeccompFilterBuilder::new(); builder.add_rule(ScmpAction::Allow, ScmpSyscall::read)?; builder.add_rule(ScmpAction::Allow, ScmpSyscall::write)?; // ... 只允许 87 个 syscall builder.add_rule(ScmpAction::KillProcess, ScmpSyscall::openat)?; // 禁用 openat

编译时启用 feature "seccomp"，确保规则生效。

Patch 2：memory region 校验
在 src/vmm/src/cpu_manager.rs 的 CpuManager::create_vcpu() 中，我们添加：

// 校验 guest memory 是否 mlock let mem_fd = unsafe { libc::open("/proc/self/fd/...", libc::O_RDONLY) }; let mut stat: libc::stat = std::mem::zeroed(); unsafe { libc::fstat(mem_fd, &mut stat) }; if stat.st_size != expected_mem_size { error!("Memory size mismatch: {} != {}", stat.st_size, expected_mem_size); std::process::exit(1); }

Patch 3：vCPU exit reason 严格过滤
在 src/vmm/src/cpu_manager.rs 的 CpuManager::run_vcpu() 中：

match exit_reason { VcpuExitReason::IoIn => handle_io_in(), VcpuExitReason::IoOut => handle_io_out(), VcpuExitReason::MmioRead => handle_mmio_read(), VcpuExitReason::MmioWrite => handle_mmio_write(), _ => { error!("Unexpected vcpu exit: {:?}", exit_reason); // 记录 crash log 并 kill std::fs::write("/var/log/firecracker-crash.log", format!("{:?}", exit_reason)).ok(); std::process::exit(127); } }

Patch 4：config.json 哈希校验
在 src/vmm/src/lib.rs 的 load_config() 中：

let config_bytes = std::fs::read(config_path)?; let config_hash = hex::encode(sha256::digest(&config_bytes)); if config_hash != EXPECTED_CONFIG_HASH { panic!("Config hash mismatch: {} != {}", config_hash, EXPECTED_CONFIG_HASH); }

编译命令：

RUSTFLAGS="-C target-cpu=native" cargo build --release --features "seccomp default" strip target/release/firecracker

最终二进制大小为 4.2MB，比官方 release 小 1.3MB，且所有 patch 都有 git commit id 记录，可追溯。

4.3 Agent Sandbox 的启动与监控：从 vmm 启动到 agent 运行的全链路观测

启动不是简单 firecracker --api-socket，而是一套带健康检查的 systemd service：

systemd unit 文件：

[Unit] Description=Firecracker Agent Sandbox After=network.target [Service] Type=exec User=firecracker Group=firecracker Environment="PATH=/usr/local/bin:/usr/bin" ExecStart=/usr/local/bin/firecracker \ --api-socket /run/firecracker.socket \ --jailer \ --id agent-sandbox-001 \ --node-ip 10.0.0.1 \ --netns /var/run/netns/firecracker-001 Restart=on-failure RestartSec=5 LimitNOFILE=65536 OOMScoreAdjust=-100 [Install] WantedBy=multi-user.target

关键点：--node-ip 指定 guest IP，--netns 指定 network namespace，确保网络隔离。我们用 iproute2 创建独立 netns：

ip netns add firecracker-001 ip link add veth0 type veth peer name veth1 ip link set veth1 netns firecracker-001 ip addr add 10.0.0.1/24 dev veth0 ip link set veth0 up ip netns exec firecracker-001 ip addr add 10.0.0.2/24 dev veth1 ip netns exec firecracker-001 ip link set veth1 up

启动后，我们用 curl 调用 Firecracker API 创建 microVM：

curl --unix-socket /run/firecracker.socket -i \ -X PUT 'http://localhost/boot-source' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "kernel_image_path": "/opt/firecracker/vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1" }'

监控不是看进程是否存在，而是三维度观测：

• VMM 层监控：用 bpftrace 抓取 vmm 的 syscall：

  bpftrace -e 'tracepoint:syscalls:sys_enter_ioctl /comm == "firecracker"/ { printf("ioctl: %d\n", args->cmd); }'

  正常应只看到 KVM_RUN、KVM_GET_VCPU_MMAP_SIZE 等少数 ioctl。

• Guest 层监控：通过 virtio-vsock 连接 guest 的 debug port：

  socat - UNIX-CONNECT:/tmp/vm.sock # guest 内 agent-runner 会输出 "AGENT STARTED"、"AGENT EXITED 0"

• Hardware 层监控：用 perf 抓取 VMX 相关事件：

  perf record -e kvm:kvm_entry,kvm:kvm_exit -a sleep 60 perf script | awk '/VMX/ {count++} END {print count}'

  正常 microVM 每秒 kvm_exit 次数应在 1000~5000 之间，过高说明频繁 trap，过低说明卡死。

我们还开发了一个 firecracker-healthcheck 工具，每 5 秒执行：

1. 检查 /proc/$(pgrep firecracker)/status 的 State 字段是否为 S（sleeping）
2. 检查 /sys/fs/cgroup/firecracker/agent-sandbox-001/memory.current 是否 < 134217728
3. 调用 curl http://localhost/metrics 获取 vmm metrics，验证 uptime_ms > 0

任何一项失败，立即 systemctl restart firecracker。

5. 常见问题与排查技巧实录

5.1 启动失败：jailer 权限拒绝与 namespace 冲突

最常见的启动失败是 jailer 报错 “Permission denied” 或 “Operation not permitted”。这不是 Firecracker bug，而是 jailer 的安全设计在起作用。我们整理了高频 case：

实操心得：我们写了一个 pre-check.sh 脚本，部署前自动运行：

#!/bin/bash test $(id -u) -eq 65534 || { echo "jailer must run as uid 65534"; exit 1; } test -d /sys/fs/cgroup || { echo "cgroup v2 not mounted"; exit 1; } test -f /proc/sys/user/max_user_namespaces || { echo "user namespace disabled"; exit 1; } sysctl -n user.max_user_namespaces | grep -q "^[1-9]" || { echo "max_user_namespaces too low"; exit 1; }

这个脚本集成在 ansible playbook 中，失败则中断部署。

5.2 Agent 启动后立即退出：guest kernel panic 或 init 失败

Agent 进程没起来，microVM 就 shutdown，日志里只有 “Shutting down VM”。这通常不是 Agent 代码问题，而是 guest 环境缺失。排查顺序如下：

1. 检查 kernel log：用dmesg -c在 host 上看是否有 “Kernel panic” 字样。常见原因是 initrd.cgz 缺少 virtio-blk.ko，导致无法挂载 rootfs。

2. 检查 init 输出：修改 config.json 的 boot_args，添加console=ttyS0和earlyprintk=serial,0x3f8，然后用socat - UNIX-CONNECT:/tmp/vm.sock连接，看 guest kernel 启动日志。如果卡在 “Waiting for root device”，说明 rootfs 路径错误或驱动缺失。

3. 检查 agent-runner 权限：在 guest 内手动执行/bin/sh，然后ls -l /bin/agent-runner。如果显示 “Permission denied”，说明 binary 没有 execute bit，或 libc.so.6 版本不匹配。

4. 检查 overlayfs upperdir：