agent-readings

Isolation and Sandboxing

Firecracker

Firecracker makes hardware virtualization viable for dense serverless multi-tenancy by replacing general-purpose QEMU with a small Rust VMM specialized for Linux microVMs.

7Claims
7Evidence

Why It Matters

For agent infrastructure, Firecracker is the practical default answer when untrusted agent-generated code needs a real tenant boundary without giving up cloud-scale density.

Problem

  • Serverless providers need to run many tenants on the same hardware while preserving security, performance isolation, and fast startup.
  • Linux containers are dense and fast but share the host kernel, creating a security-versus-compatibility tradeoff through seccomp and syscall restrictions.
  • Traditional VMs provide stronger boundaries but carry large VMM, device-model, memory, and boot-time overheads.
  • AWS Lambda originally used containers per function with EC2 instances per customer, which complicated packing and still left a container compatibility/security tradeoff.

Key gap: The paper asks whether a VM boundary can be made cheap enough for serverless function/container density while preserving broad Linux compatibility.

Method

Keep the hardware virtualization boundary but aggressively specialize the VMM for serverless: minimal devices, one process per microVM, Rust implementation, REST configuration API, Linux/KVM host primitives, and no BIOS, PCI, migration, GPU, USB, or arbitrary-kernel support.

  • Use KVM for hardware virtualization instead of relying only on host-kernel container isolation.
  • Replace QEMU with a purpose-built Rust VMM around 50k lines of code.
  • Expose only the devices required by serverless/container workloads.
  • Boot minimal Linux kernels directly, avoiding BIOS and legacy hardware emulation.
  • Provide a REST-over-Unix-socket API for microVM configuration and lifecycle control.
  • Run each microVM as a separate host process so standard Linux tools and isolation mechanisms still apply.
  • Integrate microVM slots into Lambda's worker placement and sticky routing architecture.
  • Benchmark boot time, memory overhead, IO, networking, density, and production migration behavior.

Claims

C1 · paper-supported

Firecracker shifts the isolation boundary from shared host-kernel container isolation to KVM-backed virtualization with a much smaller VMM than QEMU.

Scope: Sections 1-3.

  • E-isolation-boundary: The paper contrasts containers, where untrusted code calls the host kernel directly, with KVM virtualization, where untrusted code runs with a guest kernel and the VMM/KVM boundary mediates privileged host access.

C2 · paper-supported

The low overhead comes from specialization: Firecracker omits BIOS, arbitrary kernels, PCI, USB, video, audio, migration, and many legacy devices.

Scope: Section 1.1 and Section 3.

  • E-specialization: Firecracker intentionally does not provide BIOS, arbitrary-kernel boot, legacy devices, PCI, USB, GPU, video/audio, or migration, and exposes only a limited device set such as network, block, serial, and partial i8042.

C3 · paper-supported

Firecracker is roughly 50k lines of Rust, around 96% fewer lines than QEMU in the paper's comparison.

Scope: Section 2.1.3.

  • E-loc: The paper states QEMU is over 1.4 million lines of code, while Firecracker contains approximately 50k lines of Rust, about 96% fewer lines.

C4 · paper-supported

With a minimal Linux guest, Firecracker offers less than 5MB memory overhead, boots to application code in under 125ms in the paper's introduction claim, and can create up to 150 microVMs per second per host.

Scope: Introduction.

  • E-headline-performance: The introduction reports less than 5MB memory overhead per container, boot to application code in less than 125ms, and up to 150 microVM creations per second per host.

C5 · paper-supported

In the evaluation, Firecracker has around 3MB memory overhead per microVM, compared with around 13MB for Cloud Hypervisor and around 131MB for QEMU.

Scope: Section 5.2.

  • E-memory-overhead: The memory-overhead benchmark reports about 3MB for Firecracker, about 13MB for Cloud Hypervisor, and about 131MB for QEMU across measured VM sizes.

C6 · paper-supported

AWS migrated Lambda to Firecracker without customer behavior changes and runs Lambda and Fargate workloads on it at massive production scale.

Scope: Abstract, Section 4.3, and Conclusion.

  • E-production-migration: The paper states Firecracker is deployed in Lambda and Fargate, supports millions of workloads and trillions of requests per month, and that Lambda migration from the legacy isolation stack proceeded with no interruption to availability, latency, or behavior.

C7 · paper-supported

Firecracker's IO and networking paths were adequate for Lambda/Fargate but left room for improvement, including serial block IO handling and no flush-to-disk in the tested block path.

Scope: Sections 5.3 and 5.4.

  • E-io-limitations: The paper reports Firecracker's block IO implementation did not implement flush-to-disk and handled IO serially in the evaluated version; network throughput was lower than Cloud Hypervisor/QEMU but adequate for production needs.

Agent Infrastructure Takeaways

  • When an agent can run arbitrary code, a VM boundary is the honest security default for multi-tenant or untrusted workloads.
  • Firecracker's lesson is deletion as security engineering: remove devices, firmware, compatibility paths, and management features not required by the workload.
  • Agent sandboxes should separate orchestration from execution. Firecracker gives a microVM, not a policy engine, scheduler, package manager, or permission system.
  • Cold-start and memory overhead are product constraints. Fine-grained agent tool execution needs sandbox creation and recycling to be fast enough for interactive loops.
  • Reuse is dangerous unless scoped. Lambda reuses a slot for one function's serial invocations; agent runtimes need similarly strict tenant/function boundaries.
  • Isolation is not observability. Firecracker must still be paired with logs, metrics, cgroups/rate limits, provenance, and external side-effect controls.

Caveats

  • The paper is AWS-authored and reports AWS production experience.
  • Firecracker is not a general VM replacement; it intentionally omits many VM features.
  • Firecracker secures the compute boundary but does not solve tool authorization, data exfiltration, prompt injection, or network policy alone.
  • Boot and memory results depend on minimal kernel/userland configuration and may not hold for arbitrary guest images.
  • The 2020 IO limitations may have changed in current releases, so modern deployment decisions should rebenchmark current Firecracker.
  • A microVM boundary can still leak through explicitly granted capabilities such as filesystem mounts, network egress, credentials, or host APIs.