| Make sure you have provided the following information: |
| |
| - [ ] link to your code branch cloned from rhboot/shim-review in the form user/repo@tag |
| - [ ] 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: |
| `[your text here]` |
| |
| ###### What product or service is this for: |
| `[your text here]` |
| |
| ###### 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. |
| `[your text here]` |
| |
| ###### What's the justification that this really does need to be signed for the whole world to be able to boot it: |
| `[your text here]` |
| |
| ###### How do you manage and protect the keys used in your SHIM? |
| `[your text here]` |
| |
| ###### Do you use EV certificates as embedded certificates in the SHIM? |
| `[your text here]` |
| |
| ###### If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ? |
| `[your text here]` |
| |
| ###### Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ? |
| `[your text here]` |
| |
| ###### 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 ? |
| `[your text here]` |
| |
| ###### "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 |
| `[your text here]` |
| |
| ##### Were your old SHIM hashes provided to Microsoft ? |
| `[your text here]` |
| |
| ##### 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 ? |
| `[your text here]` |
| |
| ##### 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 ? |
| `[your text here]` |
| |
| ###### What is the origin and full version number of your bootloader (GRUB or other)? |
| `[your text here]` |
| |
| ###### If your SHIM launches any other components, please provide further details on what is launched |
| `[your text here]` |
| |
| ###### 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 |
| `[your text here]` |
| |
| ###### 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. |
| `[your text here]` |
| |
| ###### How do the launched components prevent execution of unauthenticated code? |
| `[your text here]` |
| |
| ###### Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)? |
| `[your text here]` |
| |
| ###### What kernel are you using? Which patches does it includes to enforce Secure Boot? |
| `[your text here]` |
| |
| ###### What changes were made since your SHIM was last signed? |
| `[your text here]` |
| |
| ###### What is the SHA256 hash of your final SHIM binary? |
| `[your text here]` |
