Firecracker

A microVM monitor built by AWS for Lambda, using KVM but replacing the general-purpose device model with a minimal one — block, net, serial and little else. The design goal is to make a VM cheap enough to create per request, and the security property in this spoke is a side effect of that: fewer emulated devices means less to attack.

It enters the corpus as the thing that held. In vms-wont-contain-agents the same agent that escaped QEMU/KVM three times could not escape Firecracker, which the researcher calls a "substantially harder target" — with two qualifiers this page keeps attached:

• The agent still hard-locked the host through Linux kernel flaws. Isolation survived; availability did not.
• The test was incomplete by the author's own statement — the agent "may have, given even more time." "Not escaped in this run" is the claim; "cannot be escaped" is not.

What the project says about its own boundary (repo docs, read 2026-09-23)

Sent by the curator as the repository itself (firecracker-microvm/firecracker: Rust, Apache-2.0, ~36.9k★, v1.17.0 released 2026-09-10). Its own documents describe the security model in terms that match the qualifiers above. These are first-party statements about the design, checkable in the source.

• Guest code is hostile from the first instruction. The design doc: "all vCPU threads are considered to be running malicious code as soon as they have been started." Containment is a set of nested trust zones, from guest vCPU threads out to the host, with a barrier at each step. One is the I/O thread, which copies all outbound network data to the host TAP device and applies rate limits there.
• The VM is only the first wall. The design requires process-level confinement as well: default seccomp filters, installed per thread before any guest code runs, that allow "the bare minimum set of system calls"; and the jailer, which sets up cgroups and a chroot, drops privileges and then execs Firecracker as an unprivileged process. The docs say production should start Firecracker "only via the jailer".
• Two things it leaves to the operator. "Firecracker does not perform any network traffic filtering" (egress is untrusted and must be filtered on the host), and the README says the overall security of a microVM "depends on a well configured Linux host operating system", with a production host-setup guide.
• The minimal device model, in the docs' words: VirtIO net, block and vsock, a serial console, and a partial keyboard controller whose only job is to let the guest request a reset.

That last dependency explains the first qualifier above. The agent in vms-wont-contain-agents did not break the VMM. It hard-locked the host through Linux kernel flaws, and the project itself says its security rests on that host.

Speed, as specified (maker's numbers, CI-enforced where marked). SPECIFICATION.md promises, on M5D/M6G metal: the VMM ready in 8 CPU-ms (wall-clock 6–60 ms, typically ~12); ≤ 5 MiB VMM memory overhead for a 1-vCPU/128 MiB guest; ≤ 125 ms from InstanceStart to guest /sbin/init. The CPU and I/O figures (> 95% of bare metal, 14.5–25 Gbps network, 1 GiB/s storage) are marked "integration test pending", so they are targets rather than checked results.

Cross-spoke: ../cloud-wiki holds it as the substrate under aws-lambda-microvms (the product you rent), and ../platform-ops-wiki's compute-sandbox holds it as one of two isolation choices for ephemeral untrusted workloads. Here it is a hardening decision — see hypervisor-isolation.

Related

hypervisor-isolation · vms-wont-contain-agents · system-hardening · compute-sandbox · aws-lambda-microvms