This repo is for review of our request for signing shim.
Nikolai Kostrigin for Basealt Ltd. (Bazalt Svobodnoe Programmnoe Obespechenie, OOO) https://www.basealt.ru
OS ALT https://www.basealt.ru/go/download/
What's the justification that this really does need to be signed for the whole world to be able to boot it?
OS ALT is a GNU/Linux distribution supporting Secure Boot
- Name: Dmitry Levin
- Position: Principal Software Engineer
- Email address: ldv@altlinux.ru
- PGP key fingerprint: 296D 6F29 A020 808E 8717 A884 2DB5 BD89 A340 AEB7
- PGP key: https://github.com/realnickel/shim-review/blob/BaseALT-shim15.5-ia32-x64-20220418/ldv.pub
- Name: Nikolai Kostrigin
- Position: Software Engineer
- Email address: nickel@basealt.ru
- PGP key fingerprint: DCDA CAC0 E095 3ED0 57DF 1041 727A 4E8E 91B5 9FCF
- PGP key: https://github.com/realnickel/shim-review/blob/BaseALT-shim15.5-ia32-x64-20220418/nickel.pub
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.
That is true, furthermore this submission is based on 15.5 release.
http://git.altlinux.org/gears/s/shim.git for Sisyphus repository RPM-package build
https://github.com/rhboot/shim/releases/download/15.5/shim-15.5.tar.bz2 for submission rebuild
None. Pure upstream 15.5 release.
If bootloader, shim loading is, GRUB2: is 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, and if you are shipping the shim_lock module CVE-2021-3418
Yes
* Upstream GRUB2 shim_lock verifier or * Downstream RHEL/Fedora/Debian/Canonical like implementation ?
Downstream RHEL/Fedora/Debian/Canonical like implementation
If bootloader, shim loading is, GRUB2, and previous shims were trusting 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, and if you were shipping the shim_lock module CVE-2021-3418 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) grub2:
- were old shims hashes provided to Microsoft for verification and to be added to future DBX update ?
- Does your new chain of trust disallow booting old, 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, and if you were shipping the shim_lock module CVE-2021-3418 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) grub2 builds ?
Yes, old shim hashes (0.4, 15, 15.4) where provided to Microsoft Yes, new chain of trust doesn't contain public portion of certificate used to sign affected binaries.
Is upstream commit 1957a85b0032a81e6482ca4aab883643b8dae06e "efi: Restrict efivar_ssdt_load when the kernel is locked down" applied?
Is upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 "ACPI: configfs: Disallow loading ACPI tables when locked down" applied?
Yes, both are applied
If you use vendor_db functionality of providing multiple certificates and/or hashes please briefly describe your certificate setup.
If there are allow-listed hashes please provide exact binaries for which hashes are created via file sharing service, available in public with anonymous access for verification.
Only one built-in certificate is used. No allow-listed hashes
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.
We switched to a new certificate
What OS and toolchain must we use to reproduce this build? Include where to find it, etc. We're going to try to reproduce your build as closely as possible to verify that it's really a build of the source tree you tell us it is, so these need to be fairly thorough. At the very least include the specific versions of gcc, binutils, and gnu-efi which were used, and where to find those binaries.
If the shim binaries can't be reproduced using the provided Dockerfile, please explain why that's the case and what the differences would be.
Dockerfile for rebuild image creation is attached.
Please run:
docker build . 2>&1 |tee docker_shim_rebuild.log
while
docker build .
will also do the trick.
Dockerfile should be self-explanatory.
If additional manual review is desired then container may provide following artifacts:
- /home/builder/build-{ia32,x64}.log - shim binaries rebuild logs
- /home/builder/RPM/BUILD/shim-15.5/build-ia32/shimia32.efi - rebuilt ia32 binary
- /home/builder/RPM/BUILD/shim-15.5/build-x64/shimx64.efi - rebuilt x64 binary
- /home/builder/RPM/BUILD/shim-15.5/sha256sum.shim - sha256 hashes calculated for mentioned binaries
- /home/builder/RPM/BUILD/shim-15.5/shim{ia32,x64}.vcert.diff - side-by-side comparison of built in vendor certificates for submitted and rebuilt shim binaries
- /home/builder/RPM/BUILD/shim-15.5/shim{ia32,x64}.sbat.diff - side-by-side comparison of SBAT for submitted and rebuilt shim binaries
This should include logs for creating the buildroots, applying patches, doing the build, creating the archives, etc.
Log files of the build for ia32 and x64 are available as "build-ia32.log" and "build-x64.log" respectively.
MS Submission ID:
14123827530072655 shimia32.efi
14625774512356740 shimx64.efi