Shim 15.7 for ChromeOS Flex (with crdyboot)

[nicholasbishop]

Confirm the following are included in your repo, checking each box:

• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs
• a Dockerfile to reproduce the build of the provided shim EFI binaries

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://chromium.googlesource.com/chromiumos/shim-review/+/refs/tags/google-shim-20230418

Note: unlike our previous submissions, this one uses crdyboot rather than grub as the second-stage bootloader. More info in the submission readme.

---

What is the SHA256 hash of your final SHIM binary?

---

fe3be90c56aa829949ad716126eaab3dfeb610fc216209cd6ab0ae0eac5eccb3  shimia32.efi
9983bd0887430bf6f86b99bb0595eeb2cfa2da09c2baef7803880092c45bde66  shimx64.efi

---

What is the link to your previous shim review request (if any, otherwise N/A)?

---

#300

[aronowski]

Great job! Although I have some suggestions.

The shims have the same shim.chromeos,2 product specific generation number as in the earlier review. I'd update it to 3 (it would also allow to differentiate them from the older ones which don't have NX support).

The mainline kernel 5.10 does not have NX support, which Microsoft requires, although considering there was already an exception for the older shim, I suppose Microsoft won't mind this one.

[julian-klode]

We do not need to concern ourselves with grub and kernel NX for reviewing because that can be worked on independently.

Bumping the SBAT level for NX is wrong. It's not a security issue and doesn't change anything. Firmware that needs NX enforces NX based on the flag.

[julian-klode]

Oh I just got curious and having had a quick look at the crdyboot, it seems the kernel is not validated using the shim but using an embedded key in the crdyboot using a separate vboot library and that does not seem acceptable to me, stuff running before ExitBootServices() should always be verified by the shim or the UEFI firmware.

[nicholasbishop]

Thanks for taking a look. Can you say more about what your specific concern is with having crdyboot verify the kernel? From a cryptographic perspective everything should still be fully verified; shim verifies crdyboot (which includes the embedded pubkey), and crdyboot verifies the data in the kernel partition and the rootfs.

[julian-klode]

We're trying hard to standardize revocation mechanisms with sbat, cert mule, centralized sbat updates, and we should really get sbat for the kernel too, it seems counter constructive to the effort to allow essentially a separate shim mechanism to exist in parallel.

[nicholasbishop]

Would this concern be eased by adding support to crdyboot for checking the kernel's SBAT against the SbatLevel revocations?

It probably wouldn't make sense to add that just yet, since as you say the kernel doesn't have a .sbat section yet, but we could certainly add it when the time comes. I've written an SBAT Rust crate and we could use that in crdyboot.

[THS-on]

@nicholasbishop can you update the submission to 15.8?

While with 15.8 we allow signing systemd-boot, there currently no standardized way on how we should handle custom bootloaders. Maybe @steve-mcintyre can give more information on how we should move forward with this.