Google Git
Sign in
chromium/crdyboot/fb9cf53382983bae148571d5997c323d8b4c048c
commit
fb9cf53382983bae148571d5997c323d8b4c048c
[log]
author
Nicholas Bishop <[email protected]>
Thu May 05 19:04:17 2022
committer
Chromeos LUCI <[email protected]>
Thu May 05 21:28:59 2022
tree
df85792020aed83b9f5c737c19928b7da2f9ab15
parent
3d211dadf8e1f9e9891a3492689f7d3087223224 [diff]
vboot: Fix vb2ex_printf host output

vb2ex_printf is a variadic function used by the vboot_reference C code
to log. We provide an implementation on the Rust side using the unstable
`c_variadic` feature. This worked correctly when run in the uefi
environment, but would print incorrect values when run on the host
target (i.e. when running the vboot unit tests).

I'm not clear on exactly why the previous code didn't work; something
about how the variadic args got passed to `printf_wrapper` was
incorrect. This might be a Rust bug, or a bug in my code. At any rate,
using a single function does work correctly.

Unfortunately the printf test had to be removed since there's no easy
way to programatically read the output now, but manual testing shows it
is functioning correctly.

BUG=None
TEST=cargo xtask check
TEST=Temporarily add `panic!()` at the bottom of `test_load_kernel` to make it fail.
TEST=Run `cargo xtask check` again, observe logs contain sensible numbers.

Change-Id: I8220ffbc0c15fce929f8784f5d633282c8f75761
Reviewed-on: https://chromium-review.googlesource.com/c/crdyboot/+/3629371
Tested-by: Nicholas Bishop <[email protected]>
Commit-Queue: Jeffery Miller <[email protected]>
Tested-by: Jeffery Miller <[email protected]>
Auto-Submit: Nicholas Bishop <[email protected]>
Reviewed-by: Jeffery Miller <[email protected]>
1 file changed
tree: df85792020aed83b9f5c737c19928b7da2f9ab15
  1. .cargo/
  2. crdyboot/
  3. enroller/
  4. sbat/
  5. sbat_gen/
  6. third_party/
  7. vboot/
  8. workspace/
  9. xtask/
  10. .gitignore
  11. .gitmodules
  12. .rustfmt.toml
  13. Cargo.lock
  14. Cargo.toml
  15. LICENSE
  16. OWNERS
  17. README.md
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 xtask subdirectory contains a single binary that is used by the various xtask 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:

cargo xtask install-toolchain

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

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

sudo apt install efitools gdisk ovmf ovmf-ia32 qemu-system-x86 sbsigntool

After installing qemu, add your user to the kvm group. You will need to log out and back in for this to take effect:

sudo adduser ${USER} kvm

Building and testing

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

cargo xtask check

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

cargo xtask build

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

cargo xtask 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:

cargo xtask prep-disk

To copy the latest crdyboot build to the image:

cargo xtask update-disk

Then run it in QEMU:

cargo xtask qemu [--ia32] [--secure-boot]

Some additional build options can be set in crdyboot.toml (in the root of the repo). This file will be created automatically if it doesn't already exist by copying xtask/default.toml. 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):

cargo xtask 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.