You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firecracker aims to provide VM-level isolation guarantees and solve three challenges associated with virtualization. These are:
1009
1011
1010
1012
1. VMM and the kernel have high CPU and memory overhead for VMs.
@@ -1018,18 +1020,324 @@ AWS solves the challenges by keeping Linux KVM, but swapping QEMU with a super l
1018
1020
- Device emulation for disk, networking, and serial console (keyboard)
1019
1021
- REST based configuration API to configure, manage, start and stop MicroVMs. This replaces some of the functionality offered by libvirt.
1020
1022
- Rate limiting for network and disk. Can configure throughput and request rates. For this Firecracker implements its own solution for simplicity, rather than using cgroups
1021
-
- Firecracker also provides a metadata service that securely shares configuration information between the host and guest operating system.
1023
+
- Firecracker also provides a metadata service - MicroVM-Metadata Service (MMDS) that securely shares configuration information between the host and guest operating system.
For network and block devices, Firecracker uses `virtio` (specifically virtio-net for networking, virtio-block for storage, and virtio-vsock for socket communication). Virtio provides an open API for exposing emulated devices from hypervisors. Virtio is simple, scalable, and offers good performance through its use of paravirtualization.
On the networking side, Firecracker uses a TAP virtual network interface and encapsulates the guest OS (and the TAP device) inside their own network namespace.
1028
1032
1029
1033
For storage, AWS chooses to support block devices, rather than filesystem passthrough, as a security consideration. Filesystems are large and complex code bases, and providing only block IO to the guest protects a substantial part of the host kernel surface area.
1030
1034
1031
1035
Finally, Firecracker also has a jailer around it to provide an additional level of protection against unwanted VMM behavior (such as a bug). The jailer implements a restrictive sandbox around the guest by using a set of Linux primitives. These include chroot, pid, and network namespaces. The jailer also uses seccomp-bpf to whitelist the set of system calls that can drop to the host. This, rather than using libvirt as the jailer, also diverges from Red Hat’s architecture.
1032
1036
1037
+
**Threat containment**
1038
+
1039
+
From a security perspective, all vCPU threads are considered to be running malicious code as soon as they have been started; these malicious threads need to be contained. Containment is achieved by nesting several trust zones which increment from least trusted or least safe (guest vCPU threads) to most trusted or safest (host). These trusted zones are separated by barriers that enforce aspects of Firecracker security. For example, all outbound network traffic data is copied by the Firecracker I/O thread from the emulated network interface to the backing host TAP device, and I/O rate limiting is applied at this point. These barriers are marked in the diagram below.
To fully master Firecracker, you must understand both the user-space operations (interacting with its REST API) and the host-space operations (how KVM and the Linux kernel partition resources).
1048
+
1049
+
This guide provides a comprehensive, production-style walkthrough to configure, network, boot, and analyze a Firecracker microVM using the exact assets and versions from the official repository. It is taken from Firecracker getting started guide
Firecracker relies on the Linux Kernel-based Virtual Machine (KVM) subsystem. It uses hardware execution blocks (Intel VT-x or AMD-V) to run guest code directly on the host CPU.
1054
+
1055
+
```sh
1056
+
#!/bin/bash
1057
+
set -euo pipefail
1058
+
1059
+
echo"==> Verifying KVM virtualization support..."
1060
+
if! lsmod | grep -q kvm;then
1061
+
echo"ERROR: KVM kernel module is not loaded. Ensure hardware virtualization is enabled in BIOS.">&2
1062
+
exit 1
1063
+
fi
1064
+
1065
+
echo"==> Configuring permissions for /dev/kvm..."
1066
+
# Check if current user has RW access to KVM character device
1067
+
if [ !-r /dev/kvm ] || [ !-w /dev/kvm ];then
1068
+
echo"Current user lacks permissions for /dev/kvm. Adjusting via group management..."
1069
+
if [ "$(stat -c "%G" /dev/kvm)"="kvm" ];then
1070
+
sudo usermod -aG kvm "${USER}"
1071
+
echo"SUCCESS: User added to 'kvm' group. Please log out and back in for changes to apply."
1072
+
else
1073
+
echo"Fallback: Granting access via Access Control Lists (ACL)..."
1074
+
sudo setfacl -m u:${USER}:rw /dev/kvm
1075
+
fi
1076
+
else
1077
+
echo"KVM Permissions: OK"
1078
+
fi
1079
+
```
1080
+
1081
+
When the KVM module is active, it exposes `/dev/kvm`. Firecracker uses this file descriptor to perform setup actions via ioctl system calls. When a microVM runs, the physical CPU core transitions out of host execution mode (Root Mode) into guest execution mode (Non-Root Mode). The guest OS runs at ring 0 inside its isolated hardware execution context.
Instead of multi-gigabyte ISO files or complex disk partition maps, Firecracker requires exactly two raw components: an uncompressed raw Linux kernel image (vmlinux) and a linear ext4 filesystem image.
1086
+
1087
+
Execute this script to download the exact latest binaries from the Firecracker CI pipeline, generate custom SSH keys, and provision a mountable loop device to inject credentials directly into the root filesystem:
echo"==> Compiling optimized raw ext4 filesystem disk block..."
1130
+
sudo chown -R root:root squashfs-root
1131
+
truncate -s 1G rootfs.ext4
1132
+
sudo mkfs.ext4 -d squashfs-root -F rootfs.ext4
1133
+
sudo chown "${USER}:${USER}" rootfs.ext4
1134
+
1135
+
echo"==> Cleanup intermediate directories..."
1136
+
sudo rm -rf squashfs-root
1137
+
echo"Assets prepared successfully."
1138
+
```
1139
+
1140
+
**Step 3: Configuring Host-Side Networking**
1141
+
1142
+
Firecracker does not implement a virtual network switch. It relies on a paravirtualized network layer (`virtio-net`) linked directly to a Linux TAP interface on the host machine.
1143
+
1144
+
Run the following configuration block to create the network tunnel, establish a network bridge space, and set up network address translation (NAT) to route the guest's outbound Internet traffic through your primary network card:
1145
+
1146
+
```sh
1147
+
#!/bin/bash
1148
+
set -euo pipefail
1149
+
1150
+
TAP_DEV="tap0"
1151
+
TAP_IP="172.16.0.1"
1152
+
GUEST_IP="172.16.0.2"
1153
+
NETMASK_SHORT="/30"
1154
+
1155
+
echo "==> Tearing down old interface states if present..."
1156
+
sudo ip link del "$TAP_DEV" 2>/dev/null || true
1157
+
1158
+
echo "==> Initializing virtual TAP interface..."
1159
+
sudo ip tuntap add dev "$TAP_DEV" mode tap
1160
+
sudo ip addr add "${TAP_IP}${NETMASK_SHORT}" dev "$TAP_DEV"
**Step 4: The REST API Interactive Bootstrap Guide**
1176
+
1177
+
With your assets compiled and network tunnels listening, you can configure your MicroVM. Firecracker acts as an HTTP server bound to a local Unix Domain Socket file descriptor.
1178
+
1179
+
To visualize how these configuration inputs assemble your execution state, use the interactive panel below to select resources, view real-time API schema updates, and track the internal VMM state transitions.
1180
+
1181
+
**Step 5: Manual Orchestration and Connection**
1182
+
1183
+
If you want to spin up the machine manually using individual API endpoints, execute the following shell script. It pipes sequential configuration parameters directly into Firecracker's listening socket file descriptor:
1184
+
1185
+
```sh
1186
+
#!/bin/bash
1187
+
set -euo pipefail
1188
+
1189
+
SOCKET="/tmp/firecracker.socket"
1190
+
sudo rm -f "$SOCKET"
1191
+
1192
+
echo"==> Initializing Firecracker core listener process in background..."
- When the `mem_size_mib` value is parsed from your JSON configuration, Firecracker calls `mmap` to allocate that exact amount of continuous virtual memory from the host system.
1291
+
- This entire block is registered with KVM using the `KVM_SET_USER_MEMORY_REGION` system call. The guest operating system treats this mapped address space as its raw physical memory layout.
1292
+
- Zero-copy storage and ring buffers: Firecracker avoids the overhead of traditional hardware storage emulation. Instead, it uses VirtIO shared-memory ring buffers (Virtqueues). When the guest operating system writes data to disk:
1293
+
- The guest kernel writes the data block into a memory page shared with the host.
1294
+
- The guest registers the write request inside the descriptor ring buffer.
1295
+
- The guest vCPU signals Firecracker by executing an I/O instruction, which triggers a hardware-level exit (VMExit).
1296
+
- The host KVM module catches the exit event and passes control to the Firecracker VMM thread using a fast Linux `eventfd` notification.
1297
+
- Firecracker reads the data directly out of host memory and writes it to the backing file (`rootfs.ext4`) on the host filesystem. This process bypasses complex emulation code layers, maximizing I/O performance.
1298
+
1299
+
**Step 6: Production Scaling (Using Declarative Blueprints)**
1300
+
1301
+
To scale workloads, bypassing individual HTTP calls avoids network overhead. Firecracker can process a single declarative configuration file during startup.
0 commit comments