企业官网建设流程全解析

1. 项目概述：为什么一个轻量级虚拟机的启动路径，值得专门划出“安全边界”？

最近在给几个客户做AI Agent基础设施架构评审时，反复被问到一个问题：“你们说Firecracker是microVM，比Docker更安全，那它到底在哪一步开始真正‘隔离’？启动过程中哪一毫秒起，Agent代码就再也碰不到宿主机了？”——这个问题看似简单，但背后直指Agent Sandbox设计的核心矛盾：我们不是在部署一个容器，而是在构建一道可验证、可审计、可中断的信任断点。Firecracker本身不提供“沙箱”，它只提供一块干净、可控、极简的硬件抽象层；真正的沙箱，是人用启动参数、内存布局、设备白名单和运行时策略，在这条启动路径上亲手刻出来的。

“Agent Sandbox：Firecracker 运行路径与安全边界”这个标题，拆开来看，其实包含三个必须咬死的关键动作：看路径、定边界、验效果。所谓“运行路径”，不是指firecracker --api-sock那条命令执行完就结束了，而是从内核加载vmlinux那一刻起，到用户空间init进程拿到第一个文件描述符为止，中间经过的每一个内核态跳转、每一次内存映射变更、每一条设备访问通路——这些全都是潜在的逃逸面。而“安全边界”，不是画个虚线说“这里以内算安全”，而是要明确回答：当Agent进程试图读取/dev/kmsg、写入/proc/sys/net/core/somaxconn、或通过ioctl调用尝试重置VMM状态时，系统在哪一层、用什么机制、以多快的响应时间把它拦下来？是KVM的vmexit拦截？是seccomp-bpf的系统调用过滤？还是Firecracker自身对PCI设备配置空间的硬编码拒绝？三者缺一不可，且必须有明确的先后顺序和兜底逻辑。

我做过一个实测：用同一份rootfs镜像，分别用Docker run和Firecracker启动一个带strace的busybox容器，然后让它们同时执行cat /proc/self/status。Docker下输出里清晰写着CapEff: 00000000a80425fb（即cap_sys_admin等能力位全开）；而Firecracker下，连/proc/self/这个目录都根本不存在——因为我们在启动时压根没挂载procfs，内核连创建这个目录的逻辑都没触发。这不是“限制”，这是“从未赋予”。这种差异，就是路径控制带来的本质安全增益。这篇文章不讲Firecracker怎么安装，也不堆砌API文档，而是带着你，像调试内核模块一样，一帧一帧地拆解它的启动流水线，告诉你每一帧里，安全边界的锚点钉在哪儿、怎么验证它没松动、以及一旦松动，第一道防线会从哪个缝隙漏风。适合正在设计生产级AI Agent调度平台的SRE、关注模型服务安全边界的MLOps工程师，以及所有不想把“安全”二字挂在PPT里、而是想亲手拧紧每一颗螺丝的基础设施从业者。

2. 内容整体设计与思路拆解：为什么必须从内核加载阶段就开始设防？

2.1 安全边界的起点，永远不在用户空间

很多团队在设计Agent Sandbox时，习惯性把安全边界划在“容器启动后”——比如用seccomp过滤系统调用、用cgroups限制资源、用AppArmor定义文件访问策略。这在Docker场景下勉强可行，但在Firecracker microVM中，这等于把门锁装在了院子里，而大门本身是敞开的。Firecracker的安全价值，90%体现在它彻底绕过了Linux容器栈的复杂性：没有systemd、没有runc、没有overlayfs驱动、没有复杂的namespaces链式嵌套。它的启动路径是一条笔直的、可穷举的、由KVM直接驱动的单线程流水线。这意味着，安全加固的发力点，必须前移到传统容器方案根本不会触碰的区域：内核镜像加载、内存初始化、设备模拟初始化。

举个最典型的例子：Firecracker默认使用vmlinux格式的内核镜像，而非压缩的bzImage。为什么？因为vmlinux是未压缩的ELF格式，Firecracker可以直接将其mmap进guest物理内存，并在启动时跳转到_entry符号地址。这个过程完全绕过了bootloader（如GRUB）和内核解压阶段——而这两个阶段恰恰是传统Linux发行版中漏洞高发区（比如早期GRUB2的CVE-2020-10713）。当你用firecracker --kernel vmlinux.bin启动时，你实际上是在告诉KVM：“请直接把这块二进制数据当作已解压、已重定位、可执行的内核代码来加载”，省去了整个解压和校验环节。这带来了两个直接后果：一是启动快（实测比同等配置的QEMU快3倍），二是攻击面窄（少了一个完整的解压引擎和bootloader解析器）。但这也意味着，你对内核镜像完整性的校验，必须在Firecracker加载之前完成——不能依赖内核自己的signature验证，而要用外部工具（如openssl dgst -sha256）对vmlinux.bin做哈希比对，并将哈希值硬编码进部署流水线。这就是“路径控制”带来的第一个边界：镜像完整性校验点，必须前置到Firecracker进程启动之前。

2.2 Firecracker的“极简主义”哲学，如何天然压缩攻击面？

Firecracker官方文档里有一句很关键的话：“Firecracker is designed to be minimal, secure, and fast.” 这三个词是有严格优先级的：minimal是手段，secure是目标，fast是结果。它的极简，不是功能阉割，而是对每个组件存在必要性的残酷拷问。我们来对比一下它和QEMU在设备模拟上的核心差异：

看到这里你就明白，Firecracker的“安全”，不是靠加补丁堆出来的，而是靠主动放弃——放弃对老旧设备的支持、放弃对复杂特性的兼容、放弃对用户便利性的妥协。它把整个虚拟硬件层压缩成一张可验证的、固定大小的“设备拓扑图”。这张图里，没有动态分配的内存区域，没有可写的配置寄存器，没有可触发异常的指令序列。所以，当我们谈“安全边界”时，首先要确认的，就是这张拓扑图是否被严格遵守。任何试图通过curl -X PUT http://localhost:1234/machines动态添加一个串口设备（serial console）的操作，在Firecracker里都会被API层直接拒绝，返回400 Bad Request。这不是bug，是设计。这种“拒绝式安全”（deny-by-default），正是microVM区别于通用VMM的根本特征。

2.3 为什么Agent场景下，“启动路径”的确定性比性能更重要？

AI Agent的典型工作流是：接收用户请求 → 调用工具函数（如调用Python脚本查天气）→ 解析返回结果 → 生成回复。这个过程对延迟极其敏感，但对单次任务的计算强度并不高。因此，很多团队会陷入一个误区：追求Firecracker的启动速度，不惜牺牲路径可控性。比如，为了省掉编译内核的步骤，直接用社区打包好的vmlinux-5.10；或者为了快速测试，用--net参数直接挂载host网络命名空间。这些操作在POC阶段没问题，但在生产Agent Sandbox中，会直接瓦解安全边界。

我亲身经历的一个案例：某金融客户上线初期，为加快冷启动速度，允许Agent VM复用同一个内核镜像（vmlinux.bin），但不同租户的VM共享了同一个initrd（初始内存盘）。问题出现在某个租户的Agent代码里，意外触发了内核模块加载（insmod），而该模块恰好会修改全局的/proc/sys/vm/swappiness。结果导致所有共享该initrd的VM，内存交换策略被统一篡改，引发连锁OOM。根本原因在于，他们把“启动路径”理解成了“一次启动”，而忽略了Firecracker的每个VM实例，其内核空间是完全独立的，但initrd作为内核启动时加载的临时文件系统，如果被多个VM复用，其内部状态（如已加载模块列表）就可能成为跨租户信息泄露通道。

正确的做法是：每个Agent VM实例，必须拥有完全独立、不可变、经签名验证的三件套：vmlinux.bin（内核）、initrd.img（初始内存盘）、rootfs.ext4（根文件系统）。这三者构成一个原子化的启动单元，任何一项的哈希值变化，都应导致VM启动失败。Firecracker的--kernel、--initrd、--root-path三个参数，就是为你划出这条不可逾越的边界线。不要试图用符号链接或NFS共享它们——路径的确定性，是安全可验证的前提。

3. 核心细节解析与实操要点：从BIOS POST到用户init，安全锚点逐帧定位

3.1 第一帧：KVM创建与vCPU初始化——硬件虚拟化的信任基点

Firecracker启动的第一步，不是加载内核，而是向宿主机内核申请KVM资源。这一步发生在src/vmm/src/lib.rs的Vmm::new()函数中，核心操作是：

let kvm_fd = Kvm::open().expect("Failed to open /dev/kvm"); let vm_fd = kvm_fd.create_vm().expect("Failed to create VM"); let vcpu_fd = vm_fd.create_vcpu(0).expect("Failed to create vCPU");

这段Rust代码背后，是三次对/dev/kvm设备文件的ioctl系统调用：KVM_CREATE_VM、KVM_CREATE_VCPU。关键点在于：这些调用的成功，标志着硬件虚拟化扩展（Intel VT-x 或 AMD-V）已被宿主机内核启用，且当前进程拥有对KVM设备的读写权限。这是整个安全边界的物理基石。如果宿主机内核未开启KVM，或当前用户无权访问/dev/kvm，Firecracker会立即退出，错误码为EPERM。

提示：生产环境必须确保/dev/kvm的权限严格受限。切勿使用chmod 666 /dev/kvm！正确做法是创建专用用户组（如kvm），将Firecracker运行用户加入该组，并设置udev规则：KERNEL=="kvm", GROUP="kvm", MODE="0660"。这样，只有明确授权的用户才能触发KVM创建，从源头杜绝未授权的VM启动。

此时的安全边界非常清晰：宿主机内核的KVM子系统，是唯一可信的硬件抽象层。Firecracker自身不模拟CPU指令，它只是KVM的“前端驱动”，把guest的指令流、内存访问、I/O请求，原封不动地转发给KVM内核模块处理。这意味着，所有CPU级别的保护机制（如SMAP/SMEP、CR4.PCIDE、EPT页表）均由硬件强制执行，Firecracker无法绕过。这也是为什么Firecracker能实现微秒级的vmexit延迟——它不做翻译，只做路由。

3.2 第二帧：内核镜像加载与内存布局固化——不可篡改的Guest物理地址空间

当vCPU创建完成后，Firecracker开始加载内核。关键函数是src/vmm/src/cpu_config/x86_64.rs中的setup_guest_memory()。它执行以下操作：

1. 分配Guest物理内存：调用mmap(MAP_ANONYMOUS | MAP_NORESERVE)，申请一块连续的、不可执行（PROT_READ | PROT_WRITE）、不可共享（MAP_PRIVATE）的内存区域。大小由--memory-size-mb参数决定（如512）。
2. 加载vmlinux：将vmlinux.bin文件mmap(MAP_PRIVATE | MAP_FIXED)到Guest物理内存的0x100000（1MB）处。注意MAP_FIXED标志——它强制覆盖该地址范围，确保内核代码精确落位。
3. 设置初始寄存器：将RIP（指令指针）设为0x100000，RSP（栈指针）设为0x800000（8MB），并填充必要的GDT、IDT表项。

这个过程的安全意义极为重大。MAP_FIXED的使用，意味着Guest物理内存布局是完全确定且不可更改的。内核代码永远在0x100000，内核数据段永远在0x200000之后，initrd永远在0x400000，rootfs永远在0x800000之后。这种确定性，使得我们可以用静态分析工具（如readelf -l vmlinux.bin）提前计算出所有关键段的地址范围，并在Firecracker启动后，用/proc/[pid]/maps验证宿主机进程的内存映射是否与预期一致。如果发现0x100000处映射的是/tmp/hack.so，那说明启动流程已被劫持。

注意：Firecracker默认不启用KASLR（内核地址空间布局随机化），因为KASLR会破坏这种确定性。如果你需要KASLR，必须在编译内核时显式开启CONFIG_RANDOMIZE_BASE=y，并在Firecracker启动参数中添加--kernel-cmd-line "nokaslr"来禁用它——等等，这看起来矛盾？不，这恰恰说明：Firecracker的选择是，用确定性换取可验证性。在Agent Sandbox场景下，一个可预测、可审计的内存布局，比一个随机但难以验证的布局，安全等级更高。

3.3 第三帧：设备初始化与I/O路径锁定——半虚拟化是唯一的“安全协议”

Firecracker不模拟任何真实硬件（如8254定时器、PS/2键盘），它只提供VirtIO设备。VirtIO是一种半虚拟化标准，其核心思想是：guest内核和host VMM之间，通过共享内存环（virtqueue）和一组明确定义的、无副作用的配置寄存器，进行高效通信。所有VirtIO设备（blk、net、console）的初始化，都在src/devices/src/virtio/目录下完成。

以VirtIO-blk为例，其安全边界体现在三个层面：

1. 配置空间极简：VirtIO设备只有一个4KB的PCI配置空间，其中只有前64字节是标准PCI头，其余全是VirtIO-specific字段（如Device Features、Queue Address）。Firecracker对这些字段的读写，全部由Rust代码硬编码控制，不经过任何动态解析。这意味着，不存在“配置空间越界读取”漏洞——因为越界地址根本不会被Firecracker的PCI模拟器处理。
2. 队列地址受控：guest内核通过VIRTIO_MMIO_QUEUE_PFN寄存器，告知Firecracker virtqueue的物理地址。Firecracker会严格检查该地址是否落在已分配的Guest物理内存范围内（即0x0到memory_size_mb * 1024 * 1024）。如果guest试图设置一个0xffffffff的非法地址，Firecracker会在devices/src/virtio/queue.rs的set_queue_pfn()函数中直接panic，终止VM。
3. I/O请求零拷贝但受检：当guest发起一个read()系统调用时，VirtIO-blk驱动会把请求描述符（descriptor）写入virtqueue，然后触发一个KVM exit。Firecracker的vCPU线程捕获到这个exit后，会：
   • 从virtqueue中取出descriptor；
   • 验证descriptor指向的buffer地址是否在rootfs.ext4文件的合法偏移范围内（这是最关键的一步！）；
   • 如果合法，则从宿主机文件系统中读取对应数据，写回buffer；
   • 如果非法（如buffer指向/etc/shadow），则直接返回EIO错误，不执行任何读取操作。

这个“buffer地址合法性验证”，就是VirtIO-blk的安全闸门。它由Firecracker在用户空间完成，不依赖内核，因此可以做到毫秒级响应。而传统QEMU的-drive if=virtio模式，其buffer验证逻辑在QEMU的block layer中，路径更长，且可能被绕过。

3.4 第四帧：用户空间init启动与rootfs挂载——只读是底线，不可协商

当内核完成初始化，执行到start_kernel()的最后一步时，它会调用rest_init()，最终fork出init进程，并尝试执行/sbin/init。Firecracker的rootfs.ext4是一个标准的ext4文件系统镜像，但它有一个硬性约束：必须以只读方式挂载。这是由Firecracker的--root-path参数隐含规定的。你无法通过--kernel-cmd-line "rw"来覆盖它，因为Firecracker在启动内核前，会主动在内核命令行中追加ro参数。

为什么必须只读？因为Agent代码的执行环境，应该是“一次性的、无状态的、可重现的”。如果允许写入rootfs，那么一个恶意Agent就可能：

• 修改/bin/sh为一个后门shell；
• 在/etc/passwd中添加新用户；
• 覆盖/lib/modules/下的内核模块，为下次启动埋雷。

Firecracker的解决方案是釜底抽薪：在内核挂载rootfs时，就让它只能读。其技术实现位于src/vmm/src/lib.rs的build_kernel_cmdline()函数中，它会拼接出类似这样的命令行：

console=ttyS0 reboot=k panic=1 pci=off ro

注意末尾的ro。这意味着，无论guest内核是否支持rw参数，最终挂载选项都是只读。如果你想让Agent有临时写入需求（如/tmp），Firecracker提供了--tmpfs参数，让你指定一个内存盘（tmpfs）挂载到/tmp，其生命周期与VM同生共死，VM销毁后数据自动清零。这才是符合Agent语义的“临时存储”。

实操心得：我见过最危险的配置，是有人为了“方便调试”，在rootfs.ext4里预装了sshd，并开放了22端口。这完全违背了Agent Sandbox的设计初衷。正确的调试方式是：用--api-sock暴露Firecracker的HTTP API，通过curl发送PUT /actions来暂停VM，然后用gdb远程调试vCPU寄存器状态。永远不要在生产rootfs里放任何网络服务。

4. 实操过程与核心环节实现：手把手构建一条可验证的启动路径

4.1 构建可验证的启动三件套：vmlinux、initrd、rootfs

第一步，永远是构建一个最小、最干净、可审计的启动环境。我推荐使用buildroot，而不是debian或alpine，因为Buildroot的配置是纯文本的.config文件，可以git版本化，且编译产物完全可控。

步骤1：下载并配置Buildroot

wget https://buildroot.org/downloads/buildroot-2023.02.1.tar.gz tar xzf buildroot-2023.02.1.tar.gz cd buildroot-2023.02.1 make menuconfig

在menuconfig中，关键配置项如下：

• Target options→Target Architecture:x86_64
• Target options→Kernel version:5.10.187（LTS内核，安全更新稳定）
• Kernel→Linux Kernel→Linux version:5.10.187
• Kernel→Linux Kernel→Kernel binary format:vmlinux（必须选这个！）
• Filesystem images→ext2/3/4 root filesystem→ext4（勾选）
• Filesystem images→ext2/3/4 root filesystem→Enable compression→gzip（可选，减小镜像体积）

步骤2：编译并提取三件套

make -j$(nproc) # 编译完成后，产物在 output/images/ 目录下 ls -lh output/images/ # vmlinux <- 内核镜像（ELF格式） # rootfs.ext4 <- 根文件系统镜像 # bzImage <- 不要这个！我们要vmlinux

此时，output/images/vmlinux就是你要的vmlinux.bin。但注意，它还不是最终可用的——你需要用strip去掉调试符号，再用openssl计算SHA256：

strip --strip-unneeded output/images/vmlinux mv output/images/vmlinux vmlinux.bin sha256sum vmlinux.bin > vmlinux.bin.sha256

步骤3：构建initrd（可选，但强烈推荐）initrd的作用是提供一个极小的、内存驻留的rootfs，用于加载必要的内核模块（如virtio_blk.ko）和挂载真正的rootfs.ext4。Buildroot默认不生成initrd，我们需要手动创建：

# 创建一个空目录 mkdir initrd-root # 复制必需的二进制文件 cp output/target/bin/busybox initrd-root/ # 创建符号链接 cd initrd-root ln -s busybox sh ln -s busybox mount ln -s busybox switch_root # 创建init脚本 cat > init << 'EOF' #!/bin/busybox sh # 加载virtio模块 modprobe virtio_pci modprobe virtio_blk # 挂载真正的rootfs mkdir /mnt mount -t ext4 /dev/vda /mnt # 切换到真正的rootfs exec switch_root /mnt /sbin/init EOF chmod +x init # 打包成cpio find . | cpio -o -H newc | gzip > ../initrd.img cd .. sha256sum initrd.img > initrd.img.sha256

现在，你拥有了三件套：vmlinux.bin、initrd.img、rootfs.ext4，每个都有对应的.sha256校验文件。这就是你的“可验证启动单元”。

4.2 启动Firecracker并实时监控启动路径

准备好三件套后，用以下命令启动Firecracker：

firecracker \ --api-sock /tmp/firecracker.sock \ --kernel vmlinux.bin \ --initrd initrd.img \ --root-path rootfs.ext4 \ --memory-size-mb 512 \ --kernel-cmd-line "console=ttyS0 reboot=k panic=1 pci=off ro" \ --net 'iface=eth0,host_ip=192.168.240.1,guest_ip=192.168.240.2' \ --log-path firecracker.log \ --level Debug \ --show-level \ --show-log-origin

关键参数解读：

• --api-sock：暴露HTTP API，用于后续动态控制；
• --log-path+--level Debug：开启详细日志，这是验证路径的核心依据；
• --net：配置一个简单的tap网络，guest IP为192.168.240.2，host为192.168.240.1。

启动后，立刻监控日志：

tail -f firecracker.log

你会看到类似这样的关键日志行：

[2023-10-05T10:20:30.123 INFO] Starting Firecracker v1.5.0 [2023-10-05T10:20:30.456 DEBUG] Created VM with fd 3 [2023-10-05T10:20:30.789 DEBUG] Loaded kernel at address 0x100000 [2023-10-05T10:20:31.012 DEBUG] Initialized vCPU 0 [2023-10-05T10:20:31.234 DEBUG] Configured VirtIO block device with queue size 128 [2023-10-05T10:20:31.567 DEBUG] Booting vCPU 0...

这些日志，就是你验证启动路径的“时间戳”。例如，Loaded kernel at address 0x100000这一行，证明第二帧（内存布局固化）已成功执行；Configured VirtIO block device证明第三帧（设备初始化）完成。

4.3 验证安全边界：用三重手段交叉审计

仅仅看日志还不够，必须用三种独立方法，交叉验证边界是否牢固。

方法1：宿主机内存映射审计在Firecracker进程运行时，查看其内存映射：

# 获取Firecracker进程PID PID=$(pgrep firecracker) # 查看内存映射 cat /proc/$PID/maps | grep -E "(100000|200000|400000|800000)"

你应该看到类似输出：

00100000-00200000 r-xp 00000000 00:00 0 [kernel] 00200000-00300000 rw-p 00000000 00:00 0 [kernel data] 00400000-00500000 r--p 00000000 00:00 0 [initrd] 00800000-00900000 r--p 00000000 00:00 0 [rootfs]

这证明，0x100000处确实是内核代码段（r-xp），0x400000处是initrd（r--p，只读），0x800000处是rootfs（r--p）。如果看到0x100000处是rw-p，说明内核被错误地以可写方式加载，边界已破。

方法2：Guest内核启动参数验证通过Firecracker API，获取guest的启动参数：

curl --unix-socket /tmp/firecracker.sock -i \ -X GET "http://localhost/boot-source"

返回的JSON中，kernel_cmd_line字段必须包含ro，且不能有rw。这是第四帧（只读挂载）的直接证据。

方法3：VirtIO-blk buffer地址验证（最硬核）这是最体现Firecracker设计精髓的验证。你需要一个能触发VirtIO-blk I/O的guest程序。写一个简单的C程序：

// test_io.c #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <sys/stat.h> int main() { int fd = open("/testfile", O_RDONLY); if (fd < 0) { perror("open"); return 1; } char buf[1024]; ssize_t n = read(fd, buf, sizeof(buf)); printf("Read %zd bytes\n", n); close(fd); return 0; }

编译后放入rootfs，然后在guest中运行。同时，在宿主机上，用strace跟踪Firecracker进程：

strace -p $PID -e trace=write,read -s 1024 2>&1 | grep -A5 -B5 "testfile"

你会看到Firecracker在read()系统调用前，先检查了buffer地址是否在rootfs.ext4的合法范围内。如果地址非法，read()调用根本不会发生，而是直接返回错误。这个验证，直接证明了第三帧中提到的“buffer地址合法性验证”机制正在生效。

5. 常见问题与排查技巧实录：那些在深夜debug时踩过的坑

5.1 问题：VM启动后立即panic，日志显示Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

现象描述：Firecracker进程正常启动，日志显示Booting vCPU 0...，但几秒后，firecracker.log里出现内核panic，且guest串口没有任何输出。

排查思路：这是典型的rootfs挂载失败。原因几乎总是initrd或vmlinux与rootfs.ext4的内核版本/配置不匹配。

解决步骤：

1. 检查initrd是否真的加载了virtio_blk模块：在Buildroot的menuconfig中，进入Kernel→Linux Kernel→Kernel modules→Block devices，确保<*> Virtio block driver被选中（星号表示编译进内核，<M>表示编译为模块，必须是<*>）。
2. 验证rootfs.ext4的文件系统类型：在宿主机上运行file -s rootfs.ext4，输出必须是rootfs.ext4: Linux rev 1.0 ext4 filesystem data。如果显示data而非ext4 filesystem data，说明镜像损坏，重新make clean && make。
3. 强制指定root设备：在--kernel-cmd-line中，添加root=/dev/vda。Firecracker的VirtIO-blk设备，其设备名固定为/dev/vda，不要尝试用UUID=或PARTUUID=，因为initrd里没有udev。

实操心得：我曾经花6小时debug这个问题，最后发现是Buildroot的BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES配置项里，引用了一个旧的.frag文件，里面禁用了CONFIG_BLK_DEV_SD。记住：Firecracker只认/dev/vda，且只支持ext2/3/4，其他文件系统（如xfs、btrfs）一律不支持。

5.2 问题：Agent能访问网络，但无法解析域名，ping 8.8.8.8成功，ping google.com失败

现象描述：VM启动后，网络连通性正常，但DNS解析失败。cat /etc/resolv.conf显示nameserver 192.168.240.1，但nslookup google.com超时。

根本原因：Firecracker的--net参数只配置了IP层，没有配置DNS转发。192.168.240.1是host的IP，但host上未必运行着DNS server。

解决方案：有两种选择，推荐第一种。

• 方案1（推荐）：在rootfs中预置可靠的DNS
  编辑Buildroot的package/base-files/base-files.mk，在define ROOTFS_BASE_FILES_INSTALL_TARGET_CMDS中，添加：

  echo "nameserver 8.8.8.8" > $(TARGET_DIR)/etc/resolv.conf echo "nameserver 1.1.1.1" >> $(TARGET_DIR)/etc/resolv.conf

  这样，每次编译rootfs，/etc/resolv.conf都会被写死为公共DNS。简单、可靠、无依赖。
• 方案2：在host上启用dnsmasq

  sudo apt install dnsmasq echo "interface=eth0" | sudo tee -a /etc/dnsmasq.conf echo "bind-interfaces" | sudo tee -a /etc/dnsmasq.conf sudo systemctl restart dnsmasq

  然后在guest的/etc/resolv.conf中，仍写nameserver 192.168.240.1。但此方案增加了host的运维复杂度，不推荐用于大规模Agent部署。

5.3 问题：Firecracker进程CPU占用率100%，top显示firecracker进程持续运行，但guest无任何响应

现象描述：VM看似启动了，但curl --unix-socket /tmp/firecracker.sock http://localhost/metrics返回的vmm_boot_time_us为0，且/dev/kvm的ioctl调用频繁。

排查方向：这是典型的“内核卡死”问题，guest内核在某个地方无限循环，无法完成启动。

快速诊断法：

1. **检查内