Google Git
Sign in
chromium / crdyboot / 2e2b7023f77d9fc426c37347204e86b71c844a04
commit2e2b7023f77d9fc426c37347204e86b71c844a04[log] [tgz]
authorNicholas Bishop <nicholasbishop@google.com>Tue Aug 24 21:54:52 2021
committerCommit Bot <commit-bot@chromium.org>Fri Aug 27 14:30:41 2021
tree7f43cee768244de6980955c5c7d88f3ca5a6fa9a
parent47297915c411b4a00a9de38a7dce4934994b2a29 [diff]
Use cargo workspaces

Rather than having four entirely separate crates (tools, enroller,
vboot, and crdyboot), use [cargo workspaces].

This is primarily being done as a step toward using the [xtask] pattern,
but it also fixes the issue with compiler message paths, allowing all
the RUSTFLAGS hacks to be removed.

A few notes:
- Packages in a workspace share a single Cargo.lock file, so the
  per-crate ones have been removed.
- The resolver setting goes in the root workspace crate, so moved that
  out of the per-crate Cargo.tomls.
- Same for profiles, moved overflow-checks to the root Cargo.toml.
- All build output now goes to the target directory in the workspace
  root, so updated a few paths for that.

[cargo workspaces]: https://doc.rust-lang.org/cargo/reference/workspaces.html
[xtask]: https://github.com/matklad/cargo-xtask/

BUG=None
TEST=./x.py check && ./x.py build-enroller && ./x.py update-disk

Change-Id: Ie89be641deeda3b5140b2b4b233b954d0245e04b
Reviewed-on: https://chromium-review.googlesource.com/c/crdyboot/+/3122929
Tested-by: Nicholas Bishop <nicholasbishop@google.com>
Reviewed-by: Esther Shimanovich <eshimanovich@google.com>
Commit-Queue: Nicholas Bishop <nicholasbishop@google.com>
14 files changed
tree: 7f43cee768244de6980955c5c7d88f3ca5a6fa9a
  1. crdyboot/
  2. enroller/
  3. third_party/
  4. tools/
  5. vboot/
  6. workspace/
  7. .gitignore
  8. .gitmodules
  9. .rustfmt.toml
  10. Cargo.lock
  11. Cargo.toml
  12. LICENSE
  13. OWNERS
  14. README.md
  15. x.py
README.md

crdyboot

Pronounced CUR-dee-boot.

This is a UEFI bootloader for CloudReady. Crdyboot handles loading, verifying, and running the Linux kernel.

Goals:

  • Well documented and as simple as possible.
  • Ensure that when secure boot is enabled, dm-verity is enabled for the rootfs. (Note that this can only be fully verified if using custom Secure Boot keys, otherwise a different OS signed with the Microsoft keys could be used to avoid verifying the rootfs.)
  • Use UEFI features as little as possible. We need to run on a lot of hardware, and not all UEFI implementations work well.
  • Use the ChromeOS GPT-attribute mechanism for determining which kernel to boot.
  • Use the ChromeOS kernel partitions rather than loading the kernel from the EFI partition. The kernel partitions include both the kernel data and command-line, as well as data structures to verify the signature of everything being loaded.
  • Verify the signature of everything loaded from the kernel partition.
  • Only support 64-bit CPUs, but support both 32- and 64-bit UEFI environments.

License

BSD

Code layout

The vboot subdirectory is a no_std library that handles loading and verifying the kernel. Internally it uses the LoadKernel function from third_party/vboot_reference. This crate can be built for the host target so that tests can run.

The crdyboot subdirectory contains the actual bootloader. It can only be built for the x86_64-unknown-uefi and i686-unknown-uefi targets.

The tools subdirectory contains a single binary that is used by the various x.py commands shown below.

The enroller subdirectory contains a small UEFI application that enrolls a test key in the PK, KEK, and db variables. This only works if the machine is in secure boot custom mode.

Dependencies

Install nightly Rust:

rustup install nightly
rustup component add rust-src --toolchain nightly

Provides headers needed for compiling C code compatible with the Rust UEFI targets.

sudo apt install mingw-w64-i686-dev mingw-w64-x86-64-dev

For building OVMF:

sudo apt install acpica-tools nasm uuid-dev

Other tools used for image signing and running in a VM:

sudo apt install efitools gdisk qemu-system-x86 sbsigntool

Building and testing

To check formatting, lint, test, and build both vboot and crdyboot:

./x.py check

To build crdyboot for both 64-bit and 32-bit UEFI targets:

./x.py build

One-time step to build OVMF:

./x.py build-ovmf

One-time step to enroll custom secure-boot keys:

./x.py secure-boot-setup

One-time step to copy in an existing cloudready image:

cp /path/to/cloudready.bin workspace/disk.bin

One-time step to prepare the image:

./x.py prep-disk

To copy the latest crdyboot build to the image:

./x.py update-disk

Then run it in QEMU:

./x.py qemu [--ia32] [--secure-boot]

Some additional build options can be set in crdyboot.conf (in the root of the repo). This file will be created automatically if it doesn't already exist by copying tools/default.conf. The defaults are appropriate for development. In a release build, verbose logging and the test key should be turned off.

Testing on real hardware

To test secure boot with real hardware you will need to enroll custom keys. First build the enroller image (workspace/enroller.bin):

./x.py build-enroller

Write workspace/enroller.bin to a USB, and write workspace/disk.bin to a second USB, e.g. using writedisk.

Boot the DUT and enter the boot setup. Find the secure boot settings and change it to setup mode. (The details will vary from one vendor to another.)

Plug in the enroller USB and reboot. Use the boot menu to select the USB and wait for it to complete.

Unplug the enroller USB and plug in the cloudready USB, then reboot. Use the boot menu to select the USB.

Developer notes

An older pure-Rust version can be found in the pure-rust-20210729 branch. Since then we have switched to building the C vboot library and loading/verifying the kernel through that library.