Kernel Configuration for Firecracker Agent VMs

Firecracker micro-VM isolation gives each of the AI agents its own Linux kernel, while containers share a host kernel. Kernel configuration determines which devices and syscall interfaces the agent can use, how much attack surface remains, and how quickly the VM boots. A purpose-built kernel is therefore core infrastructure for isolated agents.

Why the kernel image Firecracker boots is not a standard Linux kernel

Firecracker loads vmlinux, an uncompressed flat ELF image, in place of the bzImage that comes with a Linux distribution. It places that image directly into guest memory and jumps into it. There is no GRUB bootloader and no BIOS or UEFI firmware, and a minimal configuration requires no initramfs. The kernel from a package manager is therefore not a drop-in starting point for this boot path.

The mismatch extends beyond image format to the hardware the kernel expects. A distribution kernel carries support for PCI buses, physical NICs, sound hardware, USB, hotplug controllers, and power management subsystems. Firecracker instead exposes six emulated devices, namely virtio-net, virtio-balloon, virtio-block, virtio-vsock, a serial console, and a minimal keyboard controller. Its simple MMIO device model has none of the physical hardware that a general-purpose kernel expects to find. A kernel expecting PCI enumeration can hang or fail while waiting for hardware that will never appear.

With so few devices to support, infrastructure platforms such as Maritime start by building custom kernel configurations. Each agent needs a purpose-built vmlinux tailored to Firecracker’s four virtio devices.

The minimum viable kernel configuration — what must stay in and why

A minimum viable configuration must preserve the transport and drivers that make the guest usable. CONFIG_VIRTIO_MMIO supplies the transport layer, without which no virtio device is reachable. CONFIG_VIRTIO_BLK supplies the root filesystem disk driver, so omitting it prevents the VM from mounting its rootfs.

CONFIG_VIRTIO_NET gives the agent networking through the TAP device and is needed for a network-capable agent, while CONFIG_VIRTIO_VSOCKETS gives it the guest-host control channel that many orchestration layers use. The required runtime capability determines which channels the kernel must make available.

Less visible dependencies matter just as much as disk and network access. CONFIG_HW_RANDOM_VIRTIO supports entropy seeding, whose absence can leave crypto and TLS initialization blocked. CONFIG_KVM_GUEST provides paravirtualized clock support on x86 and x86_64, preventing the timekeeping drift that otherwise occurs under KVM. The option also exists for PowerPC, so it is not an x86_64-only setting. A guest that reaches userspace but cannot initialize TLS or keep reliable time is not an adequate agent runtime.

CONFIG_IP_PNP deserves separate treatment because it changes when networking becomes available. It enables kernel-level IP autoconfiguration through ip=, supporting static command-line addresses and dynamic BOOTP/RARP protocols. The kernel can bring up eth0 with the allocated IP and gateway before userspace runs. That removes the need for a DHCP client or for the guest agent to be the first process responsible for bringing up the network.

What to strip out and why stripping is itself a security decision

Once the kernel has what the agent needs, choosing what to remove is a security decision as well as cleanup. Sound, USB, Bluetooth, and physical platform drivers have no corresponding hardware in the guest. PCI bus support and hotplug controllers serve no purpose in Firecracker’s MMIO device model. Physical power management support, including CPUFREQ and ACPI beyond what Firecracker uses, is similarly unnecessary. Keeping these subsystems preserves kernel surface without adding useful agent capability.

The most consequential single setting is CONFIG_MODULES=n. With required drivers built into the kernel, disabling modules makes the init_module and finit_module interfaces unavailable for loading code. The running guest cannot reverse that compile-time choice through a permissive runtime setting. In this microVM model, the device set is known when the kernel is built and nothing hotplugs, so dynamic module loading provides no operational benefit.

That distinction is the central security value of stripping. A runtime rule governs access to code that remains present, while a compile-time exclusion removes the capability from the image. No seccomp rule or LSM policy is needed to prohibit module loading in a kernel built without it. Where lockdown is part of the design, however, CONFIG_SECURITY_LOCKDOWN_LSM=y must also be reflected in the kernel’s active LSM list at build time. Enabling the option alone is insufficient.

The value of that reduction grows with the lifetime of the guest. A permissive kernel is exposed for seconds in a stateless function, but for hours or days in an agent VM. For persistent, always-available agents, the model Maritime uses, unused kernel surface is open to attack for that whole time. Stripping it and disabling module loading make the boundary less dependent on runtime policy remaining correctly configured.

The guest kernel command line as a configuration layer in its own right

Compile-time settings define what the kernel can do, but the command line defines how it starts and fails. The familiar string console=ttyS0 reboot=k panic=1 pci=off is therefore an architectural configuration. Each parameter expresses a decision about missing hardware or failure handling. Copying the string without understanding those decisions leaves important agent behavior implicit.

pci=off tells the kernel to skip probing for PCI devices so it avoids enumeration that may never finish, console=ttyS0 sends kernel output to Firecracker’s serial port so a failed boot’s crash output can be captured, and panic=1 makes the kernel reboot one second after a panic to keep it from staying hung and using resources. Paired with it, reboot=k uses the KVM exit path rather than trying to reboot into nonexistent firmware. Together, these failure settings let the Firecracker process exit cleanly when the guest crashes.

The init= parameter makes a separate decision about process lifetime. It selects the program the kernel executes as PID 1 after mounting the rootfs. Pointing it at a purpose-built guest agent avoids the dependency ordering, socket activation, and device management overhead of systemd or OpenRC in a single-purpose machine. However, PID 1 exiting causes a kernel panic, making a return from an agent running as init a machine-level failure.

Networking has a comparable boot-time choice. With CONFIG_IP_PNP compiled in, ip= can establish a static network configuration before userspace starts. That matters when the agent must make outbound calls before its supervisor process is ready.

How kernel configuration determines snapshot portability across a fleet

Snapshot restore carries kernel decisions beyond the host on which the image first booted. During restore, Firecracker memory-maps the snapshot file, loads CPU register state, and resumes execution at the point where the guest was frozen. The guest does not know that time passed. Consequently, restore preserves the assumptions embedded in the original running machine.

CPU features are the most consequential portability trap. A snapshot baked on a host with AVX-512 can fail to restore on a host without it if the guest kernel was configured to use those instructions. The snapshot can therefore be valid on its source machine and unusable elsewhere in the fleet. A scheduler that restores agents on whichever host is least loaded cannot treat such an image as universally deployable.

The solution is to bake templates under a Firecracker CPU template pinned to the feature intersection of the entire fleet. Exposing more features on the machine that builds the snapshot can make the resulting image less useful to the scheduler. The build host’s full capability is therefore the wrong portability target. The common CPU feature set is the contract that allows an agent snapshot to restore across hosts.

Resource shape introduces another constraint. Firecracker freezes vCPU count and RAM at snapshot time and cannot change either during restore. The running kernel configuration and its resource allocation remain part of that snapshot for its lifetime. The host also needs a supported kernel: Linux kernel 5.10 is the minimum supported version, and Firecracker’s kernel support policy recommends 6.1 or later. Snapshot reuse also preserves the instabilities of an older kernel captured in the guest image.

The relationship between kernel configuration and sub-second wake latency

Kernel configuration is the largest build-time lever for cold-boot latency. Every retained subsystem that initializes during boot adds work before the agent can run. A stripped, purpose-built image initializes only the hardware and capabilities the guest needs, shortening the path to sub-second wake so the agent can respond promptly to the user as well as meet a benchmark target. The user has to wait for the agent to start work, whichever subsystem caused the delay.

Cold boot and snapshot restore nevertheless have different latency paths. Restore skips kernel initialization and resumes a frozen memory image with the agent already running. A fast original boot does not mean that initialization is repeated more quickly on every wake. Instead, configuration determines the kernel and runtime state that the snapshot preserves.

A snapshot taken mid-operation captures partial state, so an in-VM supervisor must confirm that the agent is idle and has no in-flight call before signaling the controller. The kernel configuration makes this orchestration possible through its available channels, but it does not enforce quiescence.

Copy-on-write restore patterns can branch a running VM’s memory and disk state cheaply. That enables an agent to run five candidate fixes from the same starting state and keep whichever passes. The economics depend on keeping the underlying image small enough to snapshot and copy at low cost. Kernel size thus affects both waiting time and how much isolated exploration the platform can support.

What isolation can a guest kernel not provide — and what fills the gap

A hardened guest kernel reduces attack surface inside the VM, but it does not establish the host boundary by itself. KVM hardware virtualization places the guest in its own virtual address space, separating it from host memory and other VMs’ memory. Per-thread seccomp filters then restrict the host-side Firecracker process, with separate profiles for the API server, vCPU, and VirtIO device threads. If an attack crosses the virtualization boundary, those filters limit the syscalls available to the affected thread. These are distinct layers rather than substitutes for careful guest configuration.

The jailer establishes the remaining host-side restrictions before Firecracker runs. It starts with root privileges, sets up the isolation primitives, drops privileges, and executes Firecracker. Cgroups and namespaces apply CPU pinning, memory caps, PID isolation, and network isolation. Firecracker itself does not run as root. The guest kernel therefore operates within a boundary whose enforcement also depends on the host process and its resource controls.

That separation matters for untrusted AI agents because they generate code at runtime that cannot be reviewed before execution. A prompt injection can turn a data task into an attempt to exfiltrate credentials. Containers constrain processes but retain a shared host kernel, so a vulnerability in that shared kernel can expose other tenants. Giving each agent its own microVM removes the risk that comes from sharing a guest kernel. It does not make malicious agent behavior harmless or replace controls over credentials.

Secrets should stay outside the guest, with available channels such as vsock and virtio-net supporting the handoff of ephemeral credentials. Disabling modules removes one in-guest escalation path, but credential handling remains a separate responsibility. Maritime applies this architecture by running each agent in its own Firecracker micro-VM on bare metal, with a persistent disk and a real kernel. The task is not merely to configure one VM, but to build a kernel image that the platform can deploy, isolate, and restore reliably for every user.