Linux Kernel Selection and Configuration for Agent Micro-VMs

With Firecracker micro-VM isolation for AI agents, each agent has its own guest kernel, while a container shares the host kernel. The Linux kernel that engineers choose and how they configure it thus shape isolation, boot latency, and operating cost. A production kernel must be a versioned build artifact, with its support window, compiled features, and snapshot compatibility chosen together.

Why Firecracker makes the kernel your engineering decision, not the host's

A container inherits the kernel selected by whoever provisioned its host. Its processes share that kernel’s code paths with other tenants, regardless of how their filesystems or process views are separated. Firecracker instead boots a guest kernel image supplied by the operator, without a bootloader or firmware layer. Guests on the same host run separate guest kernels, so a vulnerability in a shared guest syscall surface is no longer the direct route between tenants.

Maritime deploys each AI agent in its own Firecracker micro-VM with a dedicated kernel image. What is compiled into it affects the guest’s isolation, the work it does at boot, its resident memory, and its snapshot footprint. The kernel is a build artifact the operator owns.

Why do untrusted AI agents need their own isolated kernel?

An agent that executes code from prompts and user input cannot have its payload trusted in advance. Prompt injection can turn “summarize this CSV” into credential exfiltration, while executed code can cause resource abuse through fork bombs or disk exhaustion. In a multi-tenant deployment, there is also the risk of lateral movement. The boundary must therefore handle hostile execution as well as an application that fails in an expected way.

Containers expose the host syscall interface, narrowed by seccomp and LSM profiles. Firecracker puts each guest kernel behind KVM and a small virtio device model, including block, net, and vsock. Because it is built in Rust and has a device model kept small by design, it has a smaller host-facing attack surface. This replaces direct access to a shared guest kernel with a separate isolation boundary.

For deployments such as Maritime’s, a dedicated micro-VM makes tenant separation part of the execution architecture. Once untrusted code is running inside its own kernel, each compiled subsystem the guest does not need still adds code that is available inside it. How well isolation works therefore depends on both the micro-VM boundary and the kernel configuration behind it.

How Firecracker actually boots a guest kernel

Firecracker loads the kernel image it is given straight into guest memory. There is no GRUB, BIOS/UEFI, or real-mode boot stub, and the kernel is the first software that runs in the guest. The size of the kernel affects how much must be loaded, and its configuration sets what initialization and probing happens next. Removing unnecessary drivers eliminates boot work.

Each micro-VM runs in one Firecracker process with three thread types. The API thread handles REST over a Unix socket, the VMM thread handles device emulation, and each guest CPU has a vCPU thread in a KVM run-loop. The core hardware model includes TAP-backed virtio-net, host file-backed virtio-block, virtio-vsock, a serial console, and a minimal i8042 keyboard controller used only to stop the micro-VM. The guest does not need a general-purpose machine’s catalogue of physical device drivers.

Firecracker’s default command line is console=ttyS0 reboot=k panic=1 pci=off i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd. The reboot=k panic=1 pair turns a guest failure into a VM exit. The compiled kernel must match the assumptions in these arguments. Changes to the transport and boot-path can call for changes to those assumptions, especially for PCI and ACPI.

Choosing between supported kernel versions: 5.10, 6.1, and 6.18

Firecracker’s kernel support policy defines the validated choices. Versions outside the policy may work, but they are not periodically validated and may behave unexpectedly. The decision is therefore not simply which Linux release has the most features. It is which supported series fits the workload and the expected lifetime of its artifacts.

Firecracker added v5.10 to its support matrix at v1.0.0, and it became the minimum supported guest kernel at v1.10.0. Its minimum end-of-support date was 2024-01-31, which has already passed. That gives 5.10 a long testing pedigree and reference configurations, but makes it a legacy choice. A minimum support date is the planning anchor here.

The policy lists v6.1 support from Firecracker v1.9.0, with a minimum end-of-support date of 2026-09-02. That makes it suitable when a post-5.10 feature is required and the September 2026 window is acceptable. It lists v6.18 support from Firecracker v1.16.1, with a minimum end-of-support date of 2028-06-01. The latter is the forward-looking choice with the longest stated support horizon, rather than an automatic recommendation for every existing fleet.

The kernel source also matters. Firecracker’s validation pipelines use kernels supplied by Amazon Linux, which may contain backported patches and differ from the equivalent mainline versions. Their configurations belong with those Amazon Linux trees. A series number alone does not identify the exact kernel that was validated.

What to keep and what to strip when building a minimal guest kernel

A minimal Firecracker kernel is sized for hardware known at build time. The goal is not to remove features indiscriminately, but to decline to compile support for a world the micro-VM does not inhabit. Unnecessary drivers add initialization and probing, resident code raises the guest’s RAM floor, and unused subsystems add bug surface.

For disk access, keep CONFIG_VIRTIO_BLK, because the disk is a virtio-block device backed by a host file. For networking, the guest needs CONFIG_VIRTIO_NET and the core TCP/IP stack, and for a vsock control channel it needs CONFIG_VIRTIO_VSOCKETS. Keep CONFIG_VIRTIO_MMIO for Firecracker’s default MMIO transport, while CONFIG_KVM_GUEST, which enables CONFIG_KVM_CLOCK on x86_64, and CONFIG_PARAVIRT help the guest run efficiently.

The console needs CONFIG_SERIAL_8250 and CONFIG_SERIAL_8250_CONSOLE for ttyS0, with CONFIG_PRINTK for boot logs. Filesystem support should match the rootfs, commonly ext4, together with proc, sysfs, tmpfs, and devtmpfs. The entropy configuration includes CONFIG_HW_RANDOM_VIRTIO and CONFIG_RANDOM_TRUST_CPU, available for kernels ≥ 4.19.

Physical NIC drivers, GPUs, USB, sound, Bluetooth, Wi-Fi, and SCSI/RAID HBAs have no role in the core hardware model. Unused filesystems, including Btrfs, XFS, NFS, FUSE, and network or cluster filesystems, likewise carry parsers the workload does not need. With the required device support built in, disabling CONFIG_MODULES removes failures caused by a missing module. Production guests can also omit kernel debugging tools, heavy ftrace/kprobes, and lockdep/KASAN while retaining those tools in development configurations.

Workload dependencies can override an otherwise sensible removal. If guest software uses iptables, nftables, or a per-tenant firewall, the required netfilter support must be built in, including NF_CONNTRACK, IP_NF_NAT, and the NETFILTER_XT_MATCH_* symbols. A small kernel that cannot run the agent’s networking policy is not a correct kernel.

PCI needs similar care. Default MMIO transport does not itself need PCI enumeration, but ACPI initialization requires CONFIG_PCI even when Firecracker exposes no PCI devices. Firecracker supports ACPI on x86_64, superseding the deprecated MPTable path, and that configuration requires CONFIG_X86_MPPARSE=n and CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=n. PCI transport is separately enabled with --enable-pci, and its command line must not contain pci=off.

How to build, pin, and maintain the kernel as a versioned artifact

The build starts by pinning an exact stable kernel tag, excluding “latest” and branch tips. Firecracker provides reference configurations for supported series and architectures under resources/guest_configs/. These are validated baselines, so deviations need a workload or hardware reason. The selected source tree must also match the configuration’s provenance.

When moving a configuration from one version to another, run make olddefconfig to keep the choices already made and fill in defaults for new symbols. This is the point of greatest drift risk. A successful configuration update does not mean the new defaults preserve the intended exclusions. Review those choices so a version change does not silently reintroduce subsystems that were deliberately removed.

The reference workflow produces uncompressed ELF vmlinux on x86_64 and the PE Image from arch/arm64/boot/ on aarch64. Amazon Linux publishes micro-VM kernel sources under microvm-kernel-* tags, and those trees may carry backports needed by Firecracker features.

Test the kernel that was built before putting it in a snapshot. Then keep vmlinux immutable under a content-addressed identifier, stored with its Kconfig and exact kernel tag. That record binds the deployed binary to the choices that produced it. Versioning the kernel this way also gives every snapshot an identifiable foundation.

Why the kernel version you bake into a snapshot is effectively permanent

A snapshot preserves more than an agent’s files or application state. Firecracker records the VM’s memory contents, CPU registers, and device state. On restore, it memory-maps the snapshot file, loads CPU state, and resumes where the guest stopped. The kernel does not run initialization again, because its running state is already inside the snapshot.

So changing the kernel image in the deployment configuration leaves the kernel in an existing snapshot unchanged. The snapshot must remain compatible with that kernel, and the host Firecracker version must support the guest kernel in use. Changing the kernel requires a new artifact and migration or re-snapshotting of affected agent state.

For a fleet with a persistent snapshot per agent, that is a bulk artifact operation. Branches that let an agent try multiple approaches from the same starting state inherit the base snapshot’s kernel. Compatibility must hold across those branches, so the initial kernel decision outlives the original boot.

Snapshot size does not, however, translate directly into restore latency. Restore pays in time and RAM for only the pages touched between resume and readiness. The relevant quantity is the working set. Trimming the kernel thus reduces initialization during cold boot and the memory needed during resume, helping cold boot and restore in different ways.

How kernel config choices connect to agent economics at fleet scale

Agents spend much of their time waiting. Snapshot-and-restore scheduling changes what that waiting costs by keeping idle agents in storage, where they do not use active compute. A lean kernel supports that model through a smaller snapshot footprint and a smaller restore working set. Every agent built from the artifact gets those same savings.

Active memory matters just as directly. Megabytes of unnecessary kernel code per guest become gigabytes of host RAM across thousands of micro-VMs. That waste lowers agent density and changes the cost of serving each user. Fewer drivers and less bus enumeration that the guest does not need also make cold starts shorter, while agent products need under-one-second wake latency to feel responsive. Kernel configuration is one of the latency levers the operator controls directly.

Maritime uses Firecracker micro-VMs on bare metal with snapshot-restore scheduling to keep tenants separate and bring down the cost of idle agents. The economics depend not just on putting each user in a VM, but on what that VM costs while running, sleeping, and waking. The kernel is where isolation, latency, and cost intersect. It deserves treatment as a first-class engineering artifact.