Shim 15.4 + Critical Patches for Chrome OS (reven board)

[pnardini]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
  google/shim-review@google-shim-20210913-3
• 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 do 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 organization or people are asking to have this signed:

Google

What product or service is this for:

Chrome OS (reven board)

Please create your shim binaries starting with the 15.4 shim release tar file:

https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.4 and contains

the appropriate gnu-efi source.

Please confirm this as the origin your shim.

We can confirm that all of our shim binaries are built from the referenced tarball.

What's the justification that this really does need to be signed for the whole world to be able to boot it:

Chrome OS (reven) is a Linux distribution. We want to enable (and encourage) our user base to boot Chrome OS (reven) with secure boot enabled.

How do you manage and protect the keys used in your SHIM?

The keys used in this shim are generated and stored in an HSM. They are then encrypted for export to a signing fleet for usage in build signing by our CI pipeline, where they remain encrypted at rest. Only 4 trusted individuals in the org have access to the signing fleet machines, enforced by ACL and 2FA.

Do you use EV certificates as embedded certificates in the SHIM?

No.

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

We do not use this functionality.

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

Yes. https://chromium.googlesource.com/chromiumos/third_party/kernel/+/75b0cea7bf307f362057cc778efe89af4c615354

if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372,

CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779,

CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308,

CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705,

( July 2020 grub2 CVE list + March 2021 grub2 CVE list )

and if you are shipping the shim_lock module CVE-2021-3418

fixed ?

All of the referenced CVEs are fixed in the upstream GRUB2 2.06 release, which is what we use.

"Please specifically confirm that you add a vendor specific SBAT entry for SBAT header in each binary that supports SBAT metadata

( grub2, fwupd, fwupdate, shim + all child shim binaries )" to shim review doc ?

Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim

Shim SBAT
https://chromium.googlesource.com/external/github.com/neverware/shim-build/+/refs/tags/v10/sbat.csv

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,1,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.chromeos,1,ChromeOS,shim,15.4,https://chromium.googlesource.com/external/github.com/neverware/shim-build/

GRUB2 SBAT
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/changes/58/3069758/4/sys-boot/grub/files/sbat.csv

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.chromeos,1,ChromeOS,grub2,2.06,https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-boot/grub/grub-2.06.ebuild

We do not currently support fwupd / fwupdate.

Were your old SHIM hashes provided to Microsoft ?

N/A - This is the first shim release for Chrome OS (reven).

Did you change your certificate strategy, so that affected by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749,

CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713,

CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list )

grub2 bootloaders can not be verified ?

This is the first shim release for Chrome OS (reven). No vulnerable versions of GRUB will be verifiable by this shim as none have been signed with the key set being used.

What exact implementation of Secureboot in grub2 ( if this is your bootloader ) you have ?

* Upstream grub2 shim_lock verifier or * Downstream RHEL/Fedora/Debian/Canonical like implementation ?

Upstream grub2 shim_lock_verifier

What is the origin and full version number of your bootloader (GRUB or other)?

We build upstream GRUB 2.06:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-boot/grub/grub-2.06.ebuild
https://ftp.gnu.org/gnu/grub/grub-2.06.tar.gz

We apply three patches from Chromium OS on top of upstream 2.06:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-boot/grub/files/

0001-Forward-port-ChromeOS-specific-GRUB-environment-vari.patch
0002-Forward-port-gptpriority-command-to-GRUB-2.00.patch
b189992601-no-soft-float.patch

If your SHIM launches any other components, please provide further details on what is launched

N/A

If your GRUB2 launches any other binaries that are not Linux kernel in SecureBoot mode,

please provide further details on what is launched and how it enforces Secureboot lockdown

N/A

If you are re-using a previously used (CA) certificate, you

will need to add the hashes of the previous GRUB2 binaries

exposed to the CVEs to vendor_dbx in shim in order to prevent

GRUB2 from being able to chainload those older GRUB2 binaries. If

you are changing to a new (CA) certificate, this does not

apply. Please describe your strategy.

N/A - A new certificate is being used for this first release.

How do the launched components prevent execution of unauthenticated code?

Our shim launches grub2 built with secure-boot support.

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No.

What kernel are you using? Which patches does it includes to enforce Secure Boot?

Our kernel is based on 5.10 and has secure boot enabled.

What changes were made since your SHIM was last signed?

N/A - This is the first shim release for Chrome OS (reven). We are applying the following upstream patches on top of the 15.4 tarball:

• Don't call QueryVariableInfo() on EFI 1.10 machines shim#364
• Don't set user_insecure_mode and ignore_db in import_one_mok_state shim#362
• Broken ia32 relocs and an unimportant submodule change. shim#357
• mok: allocate MOK config table as BootServicesData shim#361

What is the SHA256 hash of your final SHIM binary?

d7cf7ab01e990fdb2e646434f27807dbc4f0450ccfde622e7a11d3c125a6e0c6 shimia32.efi
88cd3870afbfc847019b815190d7b1b36d6eb49f3ba8dd8ddee34e09e00d2d60 shimx64.efi

[julian-klode]

So I think we'd prefer to have one ChromeOS shim, and not one per board as this review says, because shim reviews don't scale well, so if the number of boards scales up, that'd be bad.

[pnardini]

The intent is for this shim to be the shim that other boards would use if needed. We specifically called out the reven board here as it is the first (and currently only) board to require a shim, and it is expected to stay that way for the forseeable future as reven runs on generic x86-based hardware. We can remove the 'reven' designator from the submission if it helps make things clearer?

[julian-klode]

It's fine just wanted to make sure

[frozencemetery]

link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
google/shim-review@google-shim-20210913-2

It's easier to work with when this is a single repo (e.g., just a github fork). The link appears to be a googlesource mirror (?) of a https://github.com/neverware/shim-review . However, at that location there is no tag google-shim-20210913-2. Instead, the last tag is google-shim-20210713. Apologies for the pedantry, but could you please confirm whether the github or googlesource repos are canonical, and which tag you are submitting?

[pnardini]

link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
google/shim-review@google-shim-20210913-2

It's easier to work with when this is a single repo (e.g., just a github fork). The link appears to be a googlesource mirror (?) of a https://github.com/neverware/shim-review . However, at that location there is no tag google-shim-20210913-2. Instead, the last tag is google-shim-20210713. Apologies for the pedantry, but could you please confirm whether the github or googlesource repos are canonical, and which tag you are submitting?

No apologies needed - happy to clarify things wherever necessary :)

What you're seeing here is a direct result of Neverware's integration with Google.

For this submission (Chrome OS - reven) the googlesource repo is canonical, and we are submitting the google-shim-20210913-2 tag. The googlesource repo was initially set up as a mirror of the github repo without sync, so it's become a fork. This was done so that this Chrome OS submission is entirely hosted and built on Google infrastructure.

The github repo is canon for CloudReady submissions, the last one of those being #193. We're not expecting a whole lot of additional activity there.

[vathpela]

What you're seeing here is a direct result of Neverware's integration with Google.

I'm not going to say you can't do that, but remember that legibility is key here - we have to be able to figure out what's going on. With that in mind, definitely don't do this: https://chromium.googlesource.com/external/github.com/neverware/shim-build/+/refs/tags/v9/shim_15.4_1bea91b_357.patch. You have patches from upstream. Format them with "git format-patch", so we can easily see what they are, and make sure the commit ID on them is the commit ID from the upstream repo.

[pnardini]

Understood @vathpela, and thank you for the feedback.

We've updated our patch files and verified that the resulting binary hashes have not changed. The new patch files should also now contain commit IDs from upstream, tying them back to their origin.

As a result our shim-build tag has been updated to https://chromium.googlesource.com/external/github.com/neverware/shim-build/+/refs/tags/v10 and our shim-review tag has been updated to https://chromium.googlesource.com/external/github.com/neverware/shim-review/+/refs/tags/google-shim-20210913-3.

All relevant links in the issue description have been updated as well. Let us know if there's anything else that could use additional clarification.

[julian-klode]

Sorry it took a bit. This all looks good to me, same as the previous Neverware submission (it took me a while to realize the word play)

Would be nice to get the Dockerfile to print the sha256, and have it in the shim-review repo, so we don't have to go around clone another repo. As the Makefile is not helpful, since I (presumably most people who can review) use podman and not docker these days.

(sorry for the noise below, I read something wrong and hit wrong buttons)

[pnardini]

Thanks Julian! We'll make some of those changes for our next submission. I'll close this issue once we get our signed binaries back from MSFT.