chore: apply updated mdformat styles

It seemingly finally got intelligent enough to realize we don't need all
these backslashes on the brackets.

Signed-off-by: Patrick Roy <[email protected]>

Author: roypat

CHANGELOG.md

@@ -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?
 

FAQ.md

@@ -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**:
 
@@ -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
 

README.md

@@ -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,

docs/api_requests/actions.md

@@ -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.

docs/api_requests/block-io-engine.md

@@ -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.

docs/api_requests/block-vhost-user.md

@@ -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).

docs/formal-verification.md

@@ -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.

docs/hugepages.md

@@ -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
@@ -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

docs/prod-host-setup.md

@@ -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.