Chapter 20: The Threat Model

Firecracker treats guest execution and guest network traffic as hostile. It trusts the host, the host-side API channel, and artifacts such as configuration and snapshot files. Those assumptions determine which failures Firecracker can contain and which failures invalidate the boundary.

The containment mechanisms are not one serial obstacle course. A virtio bug that gives an attacker code execution in the Firecracker process reaches the per-thread seccomp policy and the resources left inside the jail. A KVM bug that gives the guest execution in the host kernel does not. Seccomp filters a userspace thread's syscalls; it cannot confine code already running in the kernel.

That distinction is the center of the threat model.

Trust And Input

Firecracker's design document says that its vCPU threads must be treated as running malicious code once started. In practical terms, the guest kernel, guest userspace, virtio descriptors, MMIO and port-I/O values, and outbound packets are adversarial inputs.

The other side of the contract is just as important:

Trusted By Firecracker	Consequence
Host kernel, KVM, CPU, and firmware	A compromise here defeats the VM boundary
Host-side API client and Unix socket	Firecracker is not an authorization service for its API
Kernel image, block backing files, and configuration	The operator must authenticate and authorize these artifacts
Snapshot state and memory files	Firecracker performs compatibility and limited integrity checks, not trust establishment
Jailer paths and orchestration	Unprivileged host users must not be able to replace trusted inputs

The Firecracker process is neither an adversary nor an infallible trusted component. It is code that consumes hostile guest input. The design reduces that code and places process-level constraints around it because a device-model defect can turn guest input into execution in the VMM.

The resulting paths look like this:

The branching is deliberate: process controls matter on the VMM compromise path. Host patching and hardware mitigations matter on the direct KVM and microarchitectural paths. Host network policy matters on the packet path.

The Virtualization Boundary

Guest CPL 0 is not host CPL 0. Intel VMX non-root operation and AMD SVM guest mode retain a hardware-controlled transition to the host. EPT or NPT adds a second translation from guest-physical to host-physical memory. An ordinary guest write(2) enters the guest kernel; it does not enter the host's syscall handler.

KVM is part of this boundary, not a layer behind it. KVM_RUN enters guest execution and returns control for exits that userspace must handle, while many interrupt and emulation paths remain inside KVM. A flaw reachable in KVM can therefore attack the trusted host kernel directly. The Jailer cannot hide files from kernel-mode exploit code, and seccomp is not evaluated for operations performed inside KVM.

This is why Firecracker's production guidance begins with supported, regularly patched host kernels, current microcode, and appropriate processor mitigations. The VMM cannot compensate for a vulnerable trusted base.

The Device-Model Boundary

Unhandled KVM exits and virtio queue notifications reach Firecracker's userspace device model. Descriptor addresses, lengths, flags, indices, and device status values come from the guest. They must remain untrusted even when a normal Linux driver would only produce well-formed sequences.

The small machine model reduces the number of such parsers and state machines. There is no floppy controller, USB stack, GPU, audio device, or general firmware implementation. Current Firecracker does have more than its original block and network devices, and PCI transport is available as an opt-in path. "Minimal" therefore means deliberately bounded and reviewed, not fixed forever or immune to bugs.

Rust removes many accidental memory-management errors, but it does not prove queue arithmetic, state transitions, guest-memory bounds, or unsafe interfaces correct. Firecracker's own advisories demonstrate that distinction.

Process Containment

If a guest-controlled device path compromises the Firecracker process, Chapters 18 and 19 become relevant.

The seccomp policy restricts host syscalls by thread category. It can block an unlisted syscall or an unlisted ioctl request, but it does not isolate threads from Firecracker's shared address space, bind most operations to a particular file descriptor, or make allowed kernel paths safe. The production default traps an unmatched call; Firecracker's SIGSYS handler records the fault and terminates the process.

The Jailer restricts a different dimension: filesystem visibility, credentials, inherited descriptors, and resource limits, with optional cgroup, PID namespace, and network namespace controls. The mount/filesystem jail and uid/gid transition still matter when optional controls are absent, but operators must configure resource and namespace constraints appropriate to their deployment.

These controls compose on a userspace compromise path. An attacker must work with the process memory, descriptors, syscalls, files, credentials, namespaces, and quotas that remain. That is meaningful defense in depth, but it is not a claim that VMM code execution is harmless.

Network And Resource Boundaries

Firecracker forwards guest packets to a host TAP device and applies configured device rate limits. It does not decide which destinations a guest may reach. Routing, anti-spoofing, tenant segmentation, host-service protection, and metadata-service protection belong to the host network policy described in Chapter 21.

Rate limiting is also not complete resource isolation. A device token bucket can bound configured I/O bytes or operations, while cgroups and resource limits govern process-level CPU, memory, file-size, and descriptor use. Host storage writeback, log sinks, serial output, and other shared services need their own bounds. Firecracker 1.16 added an optional serial-output rate limiter, but the production guide still recommends disabling the serial device when it is not needed and using bounded output handling when it is.

Containers And MicroVMs

A container workload normally invokes the host kernel directly. Namespaces, cgroups, capabilities, LSM policy, and seccomp constrain what those host syscalls can do, but the reachable kernel implementation is shared with other tenants. A reachable host-kernel vulnerability may therefore cross the container boundary without first compromising a userspace VMM.

A microVM workload's ordinary syscalls invoke its guest kernel. To reach the host, the guest needs a separate path through KVM, an emulated device, a host-provided service, or the network. This removes the host's general syscall ABI from the guest workload's immediate attack surface, but it introduces KVM and the VMM device model.

Question	Container	Firecracker MicroVM
Which kernel handles workload syscalls?	Host kernel	Guest kernel
Primary isolation boundary	Host kernel policy and isolation primitives	CPU virtualization plus KVM
Host userspace parser	Container runtime mainly at setup	VMM device model throughout execution
Process seccomp target	Workload process	Firecracker host threads
Host networking policy	Still required	Still required after TAP forwarding
Trusted kernel failure	Can break container isolation	Can break VM isolation too

The comparison is about attack paths, not a numeric claim that one escape always requires more bugs. A KVM kernel flaw may be one bug. A VMM flaw may stop at a process sandbox, or it may combine with an allowed kernel flaw. A container kernel bug may be unreachable because of capabilities, seccomp, or a missing device. Configuration and patch state decide the concrete exposure.

Four Lessons From Vulnerabilities

Omitted Code Removes A Path

VENOM, CVE-2015-3456, was a QEMU floppy-controller bug reachable from a guest. Firecracker has no floppy controller, so that implementation and its parser are absent. This is the cleanest benefit of a small device model: code that is not linked into the guest-facing path cannot contain a guest-triggered bug.

The lesson is narrower than "small VMMs are safe." Every device that remains still needs correct validation.

Descriptor Bounds Are Security Boundaries

CVE-2019-18960 affected Firecracker 0.18.0 and 0.19.0 with an active vsock device. A logical error in virtio descriptor bounds allowed a malicious guest to access host-process heap memory just beyond a guest memory region. The maintainer disclosure said a crash was the usual result but could not rule out code execution in the Firecracker process. Patched 0.18.1 and 0.19.1 releases were provided.

This is the path seccomp and the Jailer are designed to constrain: hostile descriptor, userspace VMM memory error, possible VMM process compromise. It also shows why safe-language code still needs correct guest-memory arithmetic.

Transport State Is Guest Input

CVE-2026-5747 affected the opt-in virtio PCI transport in Firecracker 1.13.0 through 1.14.3 and 1.15.0. A root guest could modify queue configuration after activation and bypass validation performed during initialization. The advisory describes denial of service and, with additional guest or snapshot conditions, possible writes beyond guest memory into the host process. Firecracker 1.14.4 and 1.15.1 fixed the issue; the default MMIO transport was not affected.

The lesson is temporal: validating a value once is insufficient if the guest can mutate it after the checked state transition. Adding an optional transport also adds a distinct security surface, even when it carries the same virtio device.

Kernel Exploits Skip The Process Sandbox

CVE-2021-29657 was a KVM nested-SVM double-fetch flaw fixed by Linux commit a58d9166a756. Under the affected nested-virtualization conditions, an AMD guest could corrupt nested state and gain access to host model-specific registers. It was a KVM vulnerability, not a Firecracker advisory, and its specific reachability in a stock Firecracker guest is not established here.

Its architectural lesson is unambiguous: a direct guest-to-KVM path terminates in the host kernel. Firecracker's userspace seccomp program and jailed root do not mediate that path. Keeping the host kernel within its supported patch policy is part of the isolation design, not routine maintenance outside it.

Side Channels

VMX, SVM, seccomp, and namespaces control architectural access. They do not partition every cache, predictor, translation structure, memory bus, or sibling hardware thread. Firecracker's host guide therefore treats transient-execution and other hardware vulnerabilities as platform responsibilities.

For multi-tenant use, the guide recommends current firmware and microcode, following current kernel and processor-vendor guidance, disabling SMT when tenant separation requires it, disabling Kernel Samepage Merging, and using memory with appropriate Rowhammer mitigations. Swap must either be disabled or secured because it can persist guest memory. These are host-wide decisions with performance and operational consequences; they should be enforced and verified by the platform rather than copied as one-time shell commands from a chapter.

Trusted Snapshots

Firecracker classifies snapshot files as trusted. The VM state file includes a 64-bit CRC checked before load, but that detects accidental corruption; it does not authenticate the producer. The memory file and external block backing files need their own protection. Operators must authenticate and, when crossing a trust boundary, encrypt snapshot artifacts.

Cloning state creates a different risk. Identifiers, cached tokens, userspace PRNG state, and other supposedly unique values may be duplicated. Firecracker changes VMGenID on restore, and current releases expose a VMClock generation counter, allowing compatible guest software to react. Those notifications do not rewrite every application secret or identifier. The orchestrator and guest must define what is safe to clone, and customer-triggered snapshot creation needs host disk quotas.

The same principle applies to the API and boot artifacts: "trusted" means the threat model assumes their integrity. It does not mean Firecracker establishes that integrity itself.