Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rust update to 1.83 #4935

Merged
merged 16 commits into from
Dec 11, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
101 changes: 50 additions & 51 deletions CHANGELOG.md

Large diffs are not rendered by default.

9 changes: 4 additions & 5 deletions FAQ.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,11 +60,10 @@ minimal required device model to the guest operating system while excluding
non-essential functionality (only 6 emulated devices are available: virtio-net,
virtio-balloon, virtio-block, virtio-vsock, serial console, and a minimal
keyboard controller used only to stop the microVM). This, along with a
streamlined kernel loading process enables a \< 125 ms startup time and a \< 5
MiB memory footprint. The Firecracker process also provides a RESTful control
API, handles resource rate limiting for microVMs, and provides a microVM
metadata service to enable the sharing of configuration data between the host
and guest.
streamlined kernel loading process enables a < 125 ms startup time and a < 5 MiB
memory footprint. The Firecracker process also provides a RESTful control API,
handles resource rate limiting for microVMs, and provides a microVM metadata
service to enable the sharing of configuration data between the host and guest.

### What operating systems are supported by Firecracker?

Expand Down
18 changes: 9 additions & 9 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,7 @@ The **API endpoint** can be used to:
- 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.
- [x86_64 only] Stop the microVM.

**Built-in Capabilities**:

Expand All @@ -130,14 +130,14 @@ The **API endpoint** can be used to:

We test all combinations of:

| Instance | Host OS & Kernel | Guest Rootfs | Guest Kernel |
| :-------- | :---------------- | :----------- | :----------- |
| c5n.metal | al2 linux_5.10 | ubuntu 24.04 | linux_5.10 |
| m5n.metal | al2023 linux_6.1 | | linux_6.1 |
| m6i.metal | | | |
| m6a.metal | | | |
| m6g.metal | | | |
| m7g.metal | | | |
| Instance | Host OS & Kernel | Guest Rootfs | Guest Kernel |
| :-------- | :--------------- | :----------- | :----------- |
| c5n.metal | al2 linux_5.10 | ubuntu 24.04 | linux_5.10 |
| m5n.metal | al2023 linux_6.1 | | linux_6.1 |
| m6i.metal | | | |
| m6a.metal | | | |
| m6g.metal | | | |
| m7g.metal | | | |

## Known issues and Limitations

Expand Down
2 changes: 1 addition & 1 deletion docs/api_requests/actions.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ curl --unix-socket /tmp/firecracker.socket -i \
-d '{ "action_type": "FlushMetrics" }'
```

## \[Intel and AMD only\] SendCtrlAltDel
## [Intel and AMD only] SendCtrlAltDel

This action will send the CTRL+ALT+DEL key sequence to the microVM. By
convention, this sequence has been used to trigger a soft reboot and, as such,
Expand Down
2 changes: 1 addition & 1 deletion docs/api_requests/block-io-engine.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ system calls.

Firecracker 1.0.0 adds support for an asynchronous block device IO engine.

> \[!WARNING\]
> [!WARNING]
>
> Support is currently in **developer preview**. See
> [this section](#developer-preview-status) for more info.
Expand Down
2 changes: 1 addition & 1 deletion docs/api_requests/block-vhost-user.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Vhost-user block device

> \[!WARNING\]
> [!WARNING]
>
> Support is currently in **developer preview**. See
> [this section](../RELEASE_POLICY.md#developer-preview-features) for more info.
Expand Down
49 changes: 22 additions & 27 deletions docs/formal-verification.md
Original file line number Diff line number Diff line change
Expand Up @@ -143,45 +143,40 @@ Verification Time: 0.19135727s
## FAQ

**Q:** What is the Kani verifier?\
**A:** The
[Kani Rust Verifier](https://github.com/model-checking/kani) is a bit-precise
model checker for Rust. Kani is particularly useful for verifying unsafe code
blocks in Rust, where the
**A:** The [Kani Rust Verifier](https://github.com/model-checking/kani) is a
bit-precise model checker for Rust. Kani is particularly useful for verifying
unsafe code blocks in Rust, where the
“[unsafe superpowers](https://doc.rust-lang.org/stable/book/ch19-01-unsafe-rust.html#unsafe-superpowers)"
are unchecked by the compiler.

**Q:** What safety properties does Kani verify?\
**A:** Kani verifies memory
safety properties (e.g., invalid-pointer dereferences, out-of-bounds array
access), user-specified assertions (i.e., `assert!(...)`), the absence of
`panic!()`s (e.g., `unwrap()` on `None` values), and the absence of some types
of unexpected behavior (e.g., arithmetic overflows). For a full overview, see
the
**A:** Kani verifies memory safety properties (e.g., invalid-pointer
dereferences, out-of-bounds array access), user-specified assertions (i.e.,
`assert!(...)`), the absence of `panic!()`s (e.g., `unwrap()` on `None` values),
and the absence of some types of unexpected behavior (e.g., arithmetic
overflows). For a full overview, see the
[Kani documentation](https://model-checking.github.io/kani/tutorial-kinds-of-failure.html).

**Q:** Do we expect all contributors to write harnesses for newly introduced
code?\
**A:** No. Kani is complementary to unit testing, and we do not have
target for “proof coverage”. We employ formal verification in especially
critical code areas. Generally we do not expect someone who might not be
familiar with formal tools to contribute harnesses. We do expect all contributed
code to pass verification though, just like we expect it to pass unit test!
**A:** No. Kani is complementary to unit testing, and we do not have target for
“proof coverage”. We employ formal verification in especially critical code
areas. Generally we do not expect someone who might not be familiar with formal
tools to contribute harnesses. We do expect all contributed code to pass
verification though, just like we expect it to pass unit test!

**Q:** How should I report issues related to any Firecracker harnesses?\
**A:**
Our Kani harnesses verify safety critical invariants. If you discover a flaw in
a harness, please report it using the
**A:** Our Kani harnesses verify safety critical invariants. If you discover a
flaw in a harness, please report it using the
[security issue disclosure process](https://github.com/firecracker-microvm/firecracker/blob/main/SECURITY.md).

**Q:** How do I know which properties I should prove in the Kani
harness?\
**A:** Generally, these are given by some sort of specification. This
can either be the function contract described in its document (e.g. what
relation between input and output do callers expect?), or even something formal
such as the TCP/IP standard. Don't forget to mention the specification in your
proof harness!
**Q:** How do I know which properties I should prove in the Kani harness?\
**A:** Generally, these are given by some sort of specification. This can either
be the function contract described in its document (e.g. what relation between
input and output do callers expect?), or even something formal such as the
TCP/IP standard. Don't forget to mention the specification in your proof
harness!

**Q:** Where do I debug a broken proof?\
**A:** Check out the Kani book section
on
**A:** Check out the Kani book section on
[debugging verification failures](https://model-checking.github.io/kani/debugging-verification-failures.html).
2 changes: 1 addition & 1 deletion docs/hugepages.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Backing Guest Memory by Huge Pages

> \[!WARNING\]
> [!WARNING]
>
> Support is currently in **developer preview**. See
> [this section](RELEASE_POLICY.md#developer-preview-features) for more info.
Expand Down
8 changes: 4 additions & 4 deletions docs/prod-host-setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -254,18 +254,18 @@ echo "swap partitions present (Recommendation: no swap)" \

### Mitigating hardware vulnerabilities

> \[!CAUTION\]
> [!CAUTION]
>
> Firecracker is not able to mitigate host's hardware vulnerabilities. Adequate
> mitigations need to be put in place when configuring the host.

> \[!CAUTION\]
> [!CAUTION]
>
> Firecracker is designed to provide isolation boundaries between microVMs
> running in different Firecracker processes. It is strongly recommended that
> each Firecracker process corresponds to a workload of a single tenant.

> \[!CAUTION\]
> [!CAUTION]
>
> For security and stability reasons it is highly recommended to load updated
> microcode as soon as possible. Aside from keeping the system firmware
Expand Down Expand Up @@ -328,7 +328,7 @@ For vendor-specific recommendations, please consult the resources below:
- ARM:
[Speculative Processor Vulnerability](https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability)

##### \[ARM only\] Physical counter directly passed through to the guest
##### [ARM only] Physical counter directly passed through to the guest

On ARM, the physical counter (i.e `CNTPCT`) it is returning the
[actual EL1 physical counter value of the host][1]. From the discussions before
Expand Down
2 changes: 1 addition & 1 deletion docs/snapshotting/network-for-clones.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
This document presents a strategy to ensure continued network connectivity for
multiple clones created from a single Firecracker microVM snapshot.

> \[!CAUTION\]
> [!CAUTION]
>
> This should be considered as just an example to get you started, and we don't
> claim this is a performant or secure setup.
Expand Down
2 changes: 1 addition & 1 deletion docs/snapshotting/snapshot-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ workload at that particular point in time.

### Supported platforms

> \[!WARNING\]
> [!WARNING]
>
> The Firecracker snapshot feature is in
> [developer preview](../RELEASE_POLICY.md) on all CPU micro-architectures
Expand Down
37 changes: 17 additions & 20 deletions tests/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -400,36 +400,33 @@ setting to achieve consistent performance. Please see the `test` section of

`Q1:` *I have a shell script that runs my tests and I don't want to rewrite
it.*\
`A1:` Insofar as it makes sense, you should write it as a python test
function. However, you can always call the script from a shim python test
function. You can also add it as a microvm image resource in the s3 bucket (and
it will be made available under `microvm.slot.path`) or copy it over to a guest
filesystem as part of your test.
`A1:` Insofar as it makes sense, you should write it as a python test function.
However, you can always call the script from a shim python test function. You
can also add it as a microvm image resource in the s3 bucket (and it will be
made available under `microvm.slot.path`) or copy it over to a guest filesystem
as part of your test.

`Q2:` *I want to add more tests that I don't want to commit to the Firecracker
repository.*\
`A2:` Before a testrun or test session, just add your test
directory under `tests/`. `pytest` will discover all tests in this tree.
`A2:` Before a testrun or test session, just add your test directory under
`tests/`. `pytest` will discover all tests in this tree.

`Q3:` *I want to have my own test fixtures, and not commit them in the
repo.*\
`A3:` Add a `conftest.py` file in your test directory, and place your
fixtures there. `pytest` will bring them into scope for all your tests.
`Q3:` *I want to have my own test fixtures, and not commit them in the repo.*\
`A3:` Add a `conftest.py` file in your test directory, and place your fixtures
there. `pytest` will bring them into scope for all your tests.

`Q4:` *I want to use more/other microvm test images, but I don't want to add
them to the common s3 bucket.*\
`A4:` Add your custom images to the `build/img`
subdirectory in the Firecracker source tree. This directory is bind-mounted in
the container and used as a local image cache.
`A4:` Add your custom images to the `build/img` subdirectory in the Firecracker
source tree. This directory is bind-mounted in the container and used as a local
image cache.

`Q5:` *How can I get live logger output from the tests?*\
`A5:` Accessing
**pytest.ini** will allow you to modify logger settings.
`A5:` Accessing **pytest.ini** will allow you to modify logger settings.

`Q6:` *Is there a way to speed up integration tests execution time?*\
`A6:` You
can narrow down the test selection as described in the **Running** section. For
example:
`A6:` You can narrow down the test selection as described in the **Running**
section. For example:

1. Pass the `-k substring` option to pytest to only run a subset of tests by
specifying a part of their name.
Expand Down Expand Up @@ -643,6 +640,6 @@ sudo pip3 install pytest ipython requests psutil tenacity filelock "urllib3<2.0"
sudo env PYTHONPATH=tests HOME=$HOME ~/.local/bin/ipython3 -i tools/sandbox.py -- --binary-dir ../repro/v1.4.1
```

> \[!WARNING\]
> [!WARNING]
>
> **Notice this runs as root!**