- 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
fix: logic to detect changed files (firecracker-v1.6)
Changes: - In non PR context, return empty list for changed files. Reason: - For custom buildkite jobs or nightly tests the concept of changed files is not valid. Signed-off-by: Sudan Landge <sudanl@amazon.com>
fix: use the right base branch to detect changed files
Changes: Use either $BUILDKITE_PULL_REQUEST_BASE_BRANCH if available instead of main to get list of changed files. Reason: Comparing changed files with main leads to running unnecessary tests like buid_devctr even when there is no Dockerfile change in the release branch. Signed-off-by: Sudan Landge <sudanl@amazon.com>
tests: Install tools with `--locked` option
[ Upstream commit 8bb883111ff608dc2ca1a08d5e4eb2ddbd5c1c8b ] Without `--locked` option, installing cargo tools may fail for some reasons. `--locked` option is useful for reproducible installation since it ensures to use the exact same set of dependencies. Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
fix: Add check for known vulnerabilities in guest
[ Upstream commit a8239112d9de0cbc4291833c8f83792084de1747 ] There is a REPTAR exception reported on m6i.metal for guest kernel versions 4.14/5.10/6.1 when spectre-meltdown-checker.sh script is run inside the guest from below the tests: test_spectre_meltdown_checker_on_guest and test_spectre_meltdown_checker_on_restored_guest The same script when run on host doesn't report the exception which means the instances are actually not vulnerable to REPTAR. The only reason why the script cannot determine if the guest is vulnerable or not is because Firecracker does not expose the microcode version to the guest. The check is check_CVE_2023_23583_linux in spectre-meltdown-checker.sh Since we have a test on host and the exception in guest is not valid, we add a check to ignore this exception. There could be more such exceptions added to check_vulnerabilities_on_guest() in the future but generalising this function based on instance kernel versions etc. without more data looked like overkill right now so, the function handles the exception only for REPTAR and m6i. Signed-off-by: Sudan Landge <sudanl@amazon.com> Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
fix: Run make_release in privileged docker contaner
Otherwise it cannot dynamically download the cargo targets specified by the rust-toolchain.toml. On main, we solved this by having the targets be present in the container by default, but that would involve backporting container updates to the release branch. Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
chore: Add rust-toolchain.toml file to repository
This is needed to prevent A/B-tests across commit ranges that include a toolchain update (and associated code changes to keep Firecracker compiling) from breaking. Signed-off-by: Patrick Roy <roypat@amazon.co.uk>
chore(deps): run cargo update to update shlex
Update dependencies to mitigate https://rustsec.org/advisories/RUSTSEC-2024-0006 No actual impact to Firecracker, as shlex is used during build-time only and this is not exploitable at that point. (cherry picked from commit a74b2f58bd58b9248b0c24af9f27c7e65a0b845b) Signed-off-by: Pablo Barbáchano <pablob@amazon.com>
fix(test): correct kernel check in test_shut_down
PR #4353 upgraded versions of various rust-vmm crates that got patched for a security vulnerability found in vmm-sys-util (not affecting Firecracker). This included a new version of kvm-bindings which includes bindings from a newer kernel. In this, `struct system_event`, which is the type that KVM passes over to us during a KVM_EXIT_SYSTEM_EVENT exit, changed from being a `u64` to being a `&[u64]`. The change itself, landed in kernel 5.18. This changed, altered Firecracker logging during shutdown (in some cases), so #4353 PR made the necessary changes to fix the tests that relied on the log entry. The fix boils down to "if we are on 6.1 check for the new type of message". That caused our testing on latest Ubuntu to fail, because now it uses a 6.2 kernel. Fix the test by correctly checking if we are running on a kernel >= 5.18 (the kernel version that introduced the change in the KVM type). Signed-off-by: Babis Chalios <bchalios@amazon.es>
fix: bump rust-vmm dependencies
Update dependencies for various rust-vmm crates which made new releases to adapt to changes in vmm-sys-util crate. The vmm-sys-util changes were triggered due to a security vulnerability discovered in vmm-sys-util (Github Security Advisory id: GHSA-875g-mfp6-g7f9), affecting the serde implementation for the FamStructWrapper types. Firecracker itself is not affected by this vulnerability since we do not consume the serde feature of the FamStructWrapper type, but we will in the future. So, update the dependencies now to prepare for this and also avoid having `cargo audit` complaining to us. The most notable change here, is that we need to update our fork of kvm-bindings to bring it in-par with the upstream version. Signed-off-by: Babis Chalios <bchalios@amazon.es> Signed-off-by: Sudan Landge <sudanl@amazon.com>
chore: release v1.6.0 (tags/v1.6.0)
Update version number / CHANGELOG / CREDITS Signed-off-by: Pablo Barbáchano <pablob@amazon.com>
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/documentation/wiki/Initial-release-of-Kata-Containers-with-Firecracker-support)
and [Weaveworks Ignite](https://github.com/weaveworks/ignite).
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/api_server/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.
- 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 |
| :--------- | :----------------- | :------------- | :------------- |
| m5d.metal | al2 linux_4.1 | ubuntu 22.04 | linux_4.14 |
| m6i.metal | al2 linux_5.10 | | linux_5.10 |
| m6a.metal | al2023 linux_6.1 | | |
| m6g.metal | | | |
| c7g.metal | | | |
## 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-1zlb87h4z-NED1rBhVqOQ1ygBgT76wlg)
_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).