- Description:
- Firecracker with the chroot.dev fixes, branch chroot
- Last Change:
- Clone URL:
ssh://anon@got.v6.chroot.run/firecracker
- ED25519:
SHA256:7587EKj+viWIfWGzPGNqUFSdFEh83CZFaqnwaoNmcNc
Commit Briefs
docs(changelog): note the virtio-mem discard fixes (fix/virtio-mem-discard-upstream)
Record the snapshot-restore virtio-mem discard fixes: preserving MAP_NORESERVE so the discard mmap cannot fail with ENOMEM, and mapping each unplugged slot back to PROT_NONE so unplugged memory stays inaccessible to the VMM. Signed-off-by: Jay Chung <jaehoc@amazon.com>
fix(vmm): skip discarding a virtio-mem range with nothing plugged
handle_unplug_all_request builds a range covering the whole hotpluggable region and passed it to update_range unconditionally, so update_range ran a full-region discard on every UNPLUG_ALL even when no block in the range was plugged, repeating the same work on every such request. Return early from update_range when unplugging a range that has no plugged block: the bitmap, KVM slots and memory are already in the requested state. update_slot's own `prev == plug` guard already makes the per-slot KVM work a no-op, so this only drops the redundant discard. Signed-off-by: Jay Chung <jaehoc@amazon.com>
test(vmm): verify unplugged memory stays protected
Add an integration test that plugs the whole virtio-mem region and unplugs it, then checks the Firecracker process address space: the plug/unplug cycle must not leave a new writable anonymous mapping, i.e. unplugged slots must remain PROT_NONE after discard_range remaps them. Runs across the uvm_any_memhp matrix, so it covers the file-backed (snapshot-restored) discard path that the in-tree unit tests do not, since those use anonymous guest memory (the madvise branch). Signed-off-by: Jay Chung <jaehoc@amazon.com>
fix(vmm): abort if discarding restored guest memory fails
The discard_range snapshot-file branch re-maps each slot with a MAP_FIXED mmap, which unmaps the existing range before it can fail. On failure the range is left unmapped while the device still treats it as valid guest memory, and the caller only logged the error and carried on, so the VMM kept running on an address space inconsistent with its own bookkeeping. Panic instead. Once MAP_FIXED has unmapped the range the failure is not recoverable. The arguments are validated beforehand, so a valid request never triggers this. Signed-off-by: Jay Chung <jaehoc@amazon.com>
fix(vmm): keep unplugged memory protected when discarding it
On file-backed (snapshot-restored) guest memory, discard_range replaced the whole range with a single PROT_READ | PROT_WRITE MAP_FIXED mapping. That cleared the PROT_NONE update_slot applies to unplugged slots, so an unplugged slot was left accessible to the VMM for the rest of the process lifetime. Map each intersecting slot with its final protection in one pass instead: fully unplugged slots get PROT_NONE, plugged (or mixed) slots stay PROT_READ | PROT_WRITE. Doing it per slot rather than mapping the range writable and re-protecting afterwards avoids a window where a just-discarded slot is briefly writable. Signed-off-by: Jay Chung <jaehoc@amazon.com>
fix(vmm): preserve MAP_NORESERVE when discarding restored guest memory
The snapshot-file branch of GuestRegionMmapExt::discard_range replaces the range with a fresh MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE mapping but did not carry MAP_NORESERVE, which the original guest memory mapping was created with in `create`. Without MAP_NORESERVE the kernel reserves commit for the replacement mapping, so the mmap can fail with ENOMEM even though the original mapping it replaces did not reserve any. On host kernels that unmap the existing range before the reservation check (MAP_FIXED semantics prior to 6.9), such a failure leaves the range unmapped while the device still treats it as valid guest memory. Add MAP_NORESERVE so the replacement matches the original mapping and the discard cannot fail for reservation reasons. The seccomp filter matches mmap's flags argument exactly, so update the discard_range mmap rule for both architectures in the same commit (flags 50 -> 16434) to keep the runtime mmap from being rejected (SIGSYS) and preserve bisectability. Signed-off-by: Jay Chung <jaehoc@amazon.com>
guest_configs: Drop redundant Kconfig overrides
CONFIG_SQUASHFS_ZSTD in ci.config and CONFIG_FRAME_POINTER in debug.config are already enabled by every microvm-kernel-ci base config, so setting them again has no effect. Signed-off-by: Ilias Stamatis <ilstam@amazon.com>
guest_configs: Sync microvm Kconfigs with AL upstream
Refresh the CI guest kernel configs from the Amazon Linux microVM kernel srpm configs. Notable changes are PCIe hotplug support on all versions, and for 6.1 TUN, VXLAN, GENEVE, socket diag, CHECKPOINT_RESTORE and Landlock. Signed-off-by: Ilias Stamatis <ilstam@amazon.com>
virtio: balloon: Don't arm the stats timer of an inactive device
The update_stats_polling_interval() function arms the periodic timerfd unconditionally. A PATCH /balloon/statistics after a device reset will arm the timer. Given that there's nothing that consumes the event when the timer fires, this can cause the main thread to spin unnecessarily. Fix this by only arming the timer and notifying the guest when the device is activated. Signed-off-by: Ilias Stamatis <ilstam@amazon.com>
changelog: metion VIRTIO_BLK_F_BLK_SIZE and VIRTIO_BLK_F_TOPOLOGY
Add a note about new VIRTIO_BLK_F_BLK_SIZE and VIRTIO_BLK_F_TOPOLOGY features of the virtio-block device. Signed-off-by: Egor Lazarchuk <yegorlz@amazon.co.uk>
Branches
Tree
README.md
<picture>
<source media="(prefers-color-scheme: dark)" srcset="docs/images/fc_logo_full_transparent-bg_white-fg.png">
<source media="(prefers-color-scheme: light)" srcset="docs/images/fc_logo_full_transparent-bg.png">
<img alt="Firecracker Logo Title" width="750" src="docs/images/fc_logo_full_transparent-bg.png">
</picture>
Our mission is to enable secure, multi-tenant, minimal-overhead execution of
container and function workloads.
Read more about the Firecracker Charter [here](CHARTER.md).
## What is Firecracker?
Firecracker is an open source virtualization technology that is purpose-built
for creating and managing secure, multi-tenant container and function-based
services that provide serverless operational models. Firecracker runs workloads
in lightweight virtual machines, called microVMs, which combine the security and
isolation properties provided by hardware virtualization technology with the
speed and flexibility of containers.
## Overview
The main component of Firecracker is a virtual machine monitor (VMM) that uses
the Linux Kernel Virtual Machine (KVM) to create and run microVMs. Firecracker
has a minimalist design. It excludes unnecessary devices and guest-facing
functionality to reduce the memory footprint and attack surface area of each
microVM. This improves security, decreases the startup time, and increases
hardware utilization. Firecracker has also been integrated in container
runtimes, for example
[Kata Containers](https://github.com/kata-containers/kata-containers) and
[Flintlock](https://github.com/liquidmetal-dev/flintlock).
Firecracker was developed at Amazon Web Services to accelerate the speed and
efficiency of services like [AWS Lambda](https://aws.amazon.com/lambda/) and
[AWS Fargate](https://aws.amazon.com/fargate/). Firecracker is open sourced
under [Apache version 2.0](LICENSE).
To read more about Firecracker, check out
[firecracker-microvm.io](https://firecracker-microvm.github.io).
## Getting Started
To get started with Firecracker, download the latest
[release](https://github.com/firecracker-microvm/firecracker/releases) binaries
or build it from source.
You can build Firecracker on any Unix/Linux system that has Docker running (we
use a development container) and `bash` installed, as follows:
```bash
git clone https://github.com/firecracker-microvm/firecracker
cd firecracker
tools/devtool build
toolchain="$(uname -m)-unknown-linux-musl"
```
The Firecracker binary will be placed at
`build/cargo_target/${toolchain}/debug/firecracker`. For more information on
building, testing, and running Firecracker, go to the
[quickstart guide](docs/getting-started.md).
The overall security of Firecracker microVMs, including the ability to meet the
criteria for safe multi-tenant computing, depends on a well configured Linux
host operating system. A configuration that we believe meets this bar is
included in [the production host setup document](docs/prod-host-setup.md).
## Contributing
Firecracker is already running production workloads within AWS, but it's still
Day 1 on the journey guided by our [mission](CHARTER.md). There's a lot more to
build and we welcome all contributions.
To contribute to Firecracker, check out the development setup section in the
[getting started guide](docs/getting-started.md) and then the Firecracker
[contribution guidelines](CONTRIBUTING.md).
## Releases
New Firecracker versions are released via the GitHub repository
[releases](https://github.com/firecracker-microvm/firecracker/releases) page,
typically every two or three months. A history of changes is recorded in our
[changelog](CHANGELOG.md).
The Firecracker release policy is detailed [here](docs/RELEASE_POLICY.md).
## Design
Firecracker's overall architecture is described in
[the design document](docs/design.md).
## Features & Capabilities
Firecracker consists of a single micro Virtual Machine Manager process that
exposes an API endpoint to the host once started. The API is
[specified in OpenAPI format](src/firecracker/swagger/firecracker.yaml). Read
more about it in the [API docs](docs/api_requests).
The **API endpoint** can be used to:
- Configure the microvm by:
- Setting the number of vCPUs (the default is 1).
- Setting the memory size (the default is 128 MiB).
- Configuring a [CPU template](docs/cpu_templates/cpu-templates.md).
- Add one or more network interfaces to the microVM.
- Add one or more read-write or read-only disks to the microVM, each represented
by a file-backed block device.
- Trigger a block device re-scan while the guest is running. This enables the
guest OS to pick up size changes to the block device's backing file.
- Change the backing file for a block device, before or after the guest boots.
- Configure rate limiters for virtio devices which can limit the bandwidth,
operations per second, or both.
- Configure the logging and metric system.
- `[BETA]` Configure the data tree of the guest-facing metadata service. The
service is only available to the guest if this resource is configured.
- Add a [vsock socket](docs/vsock.md) to the microVM.
- Add a [entropy device](docs/entropy.md) to the microVM.
- Add a [pmem device](docs/pmem.md) to the microVM.
- Configure and manage [memory hotplugging](docs/memory-hotplug.md).
- `[Developer Preview]` [Hot-plug and hot-unplug](docs/device-hotplug.md) virtio
PCI devices while the VM is running.
- Start the microVM using a given kernel image, root file system, and boot
arguments.
- [x86_64 only] Stop the microVM.
**Built-in Capabilities**:
- Demand fault paging and CPU oversubscription enabled by default.
- Advanced, thread-specific seccomp filters for enhanced security.
- [Jailer](docs/jailer.md) process for starting Firecracker in production
scenarios; applies a cgroup/namespace isolation barrier and then drops
privileges.
## Tested platforms
We test all combinations of:
| Instance | Host OS & Kernel | Guest Rootfs | Guest Kernel |
| :------------------------------------------ | :---------------- | :----------- | :----------- |
| m5n.metal (Intel Cascade Lake) | al2 linux_5.10 | ubuntu 24.04 | linux_5.10 |
| m6i.metal (Intel Ice Lake) | al2023 linux_6.1 | | linux_6.1 |
| | al2023 linux_6.18 | | |
| m7i.metal-24xl (Intel Sapphire Rapids) | | | |
| m7i.metal-48xl (Intel Sapphire Rapids) | | | |
| **m8i.metal-48xl (Intel Granite Rapids)\*** | | | |
| **m8i.metal-96xl (Intel Granite Rapids)\*** | | | |
| m6a.metal (AMD Milan) | | | |
| m7a.metal-48xl (AMD Genoa) | | | |
| m6g.metal (Graviton 2) | | | |
| m7g.metal (Graviton 3) | | | |
| m8g.metal-24xl (Graviton 4) | | | |
| m8g.metal-48xl (Graviton 4) | | | |
| m9g.metal-48xl (Graviton 5) | | | |
**\***: We **only** support AWS EC2 8th Gen Intel (\*8i) instances using a 6.1
or 6.18 host kernel. This is due to poor kernel support for Granite Rapids CPUs
on 5.10.
## Known issues and Limitations
- The `pl031` RTC device on aarch64 does not support interrupts, so guest
programs which use an RTC alarm (e.g. `hwclock`) will not work.
## Performance
Firecracker's performance characteristics are listed as part of the
[specification documentation](SPECIFICATION.md). All specifications are a part
of our commitment to supporting container and function workloads in serverless
operational models, and are therefore enforced via continuous integration
testing.
## Policy for Security Disclosures
The security of Firecracker is our top priority. If you suspect you have
uncovered a vulnerability, contact us privately, as outlined in our
[security policy document](SECURITY.md); we will immediately prioritize your
disclosure.
## FAQ & Contact
Frequently asked questions are collected in our [FAQ doc](FAQ.md).
You can get in touch with the Firecracker community in the following ways:
- Security-related issues, see our [security policy document](SECURITY.md).
- Chat with us on our
[Slack workspace](https://join.slack.com/t/firecracker-microvm/shared_invite/zt-3v81btcpe-usCf8Qk7k1gUlSAEKKdYMg)
_Note: most of the maintainers are on a European time zone._
- Open a GitHub issue in this repository.
- Email the maintainers at
[firecracker-maintainers@amazon.com](mailto:firecracker-maintainers@amazon.com).
When communicating within the Firecracker community, please mind our
[code of conduct](CODE_OF_CONDUCT.md).