Lecture 2 - OS and VM isolation
0x00 Preparation
Firecracker
Read sections 1-3 of the Firecracker paper, published in 2020. Firecracker was developed by Amazon to be a small, highly secure virtual machine monitor, building on top of the KVM machinery provided by the Linux kernel. The later sections of the Firecracker paper talk about how Amazon uses Firecracker for their Lambda service, which you can skip.
A: This introduces difficult tradeoffs: implementors of serverless and container services can choose between hypervisor-based virtualization (and the potentially unacceptable overhead related to it), and Linux containers (and the related compatibility vs. security tradeoffs). We built Firecracker because we didn’t want to choose.
A: A Virtual Machine Monitor (VMM) designed for Serverless and container workloads.
A: Six key features are required
- Isolation: It must be safe for multiple functions to run on the same hardware, protected against privilege escalation, information disclosure, covert channels, and other risks.
- Overhead and Density: It must be possible to run thousands of functions on a single machine, with minimal waste.
- Performance: Functions must perform similarly to running natively. Performance must also be consistent, and isolated from the behavior of neighbors on the same hardware.
- Compatibility: Lambda allows functions to contain arbitrary Linux binaries and libraries. These must be supported without code changes or recompilation.
- Fast Switching: It must be possible to start new functions and clean up old functions quickly.
- Soft Allocation: It must be possible to over commit CPU, memory and other resources, with each function consuming only the resources it needs, not the resources it is entitled to.
A: This is shown in the following table
| Solution Type | Advantages | Disadvantages |
|---|---|---|
| Linux Containers (e.g., Docker and LXC, using cgroups, namespaces, seccomp-bpf) | - Low overhead and high density - Operational simplicity |
- Security vs. compatibility tradeoff - Shared kernel vulnerabilities |
| Language-Specific Isolation (e.g., JVM or V8, using VM isolates or process per trust domain) | - Efficient integration - Low overhead |
- Poor compatibility - Security risks |
| Virtualization (e.g., QEMU/KVM or Xen, using hardware virtualization) | - Strong isolation - Flexibility and compatibility |
- High overhead and low density - Slow startup and complexity |
A: Firecracker’s approach to these problems is to use KVM (for reasons we discuss in section 3), but replace the VMM with a minimal implementation written in a safe language. Minimizing the feature set of the VMM helps reduce surface area, and controls the size of the TCB. Firecracker contains approximately 50k lines of Rust code (96% fewer lines than QEMU), including multiple levels of automated tests, and auto-generated bindings. Intel Cloud Hypervisor [25] takes a similar approach, (and indeed shares much code with Firecracker), while NEMU [24] aims to address these problems by cutting down QEMU.