|author||Nicholas Bishop <firstname.lastname@example.org>||Tue Aug 24 21:54:52 2021|
|committer||Commit Bot <email@example.com>||Fri Aug 27 14:30:41 2021|
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 <firstname.lastname@example.org> Reviewed-by: Esther Shimanovich <email@example.com> Commit-Queue: Nicholas Bishop <firstname.lastname@example.org>
This is a UEFI bootloader for CloudReady. Crdyboot handles loading, verifying, and running the Linux kernel.
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.
crdyboot subdirectory contains the actual bootloader. It can only be built for the
tools subdirectory contains a single binary that is used by the various
x.py commands shown below.
enroller subdirectory contains a small UEFI application that enrolls a test key in the
db variables. This only works if the machine is in secure boot custom mode.
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
To check formatting, lint, test, and build both vboot and crdyboot:
To build crdyboot for both 64-bit and 32-bit UEFI targets:
One-time step to build OVMF:
One-time step to enroll custom secure-boot keys:
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:
To copy the latest crdyboot build to the image:
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.
To test secure boot with real hardware you will need to enroll custom keys. First build the enroller image (
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.
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.