Debian GNU/Linux 10 shim-15.4-6 x64 and ia32 (20210623)

[steve-mcintyre]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
  https://github.com/steve-mcintyre/shim-review/tree/debian-10-shim-i386-20210623 (ia32)
  https://github.com/steve-mcintyre/shim-review/tree/debian-10-shim-amd64-20210623 (x64)
  (These are identical except for the Dockerfile - the i386 build seems to specifically need an i386 docker image to be used. Yay Docker)
• 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:

Debian

What product or service is this for:

Debian GNU/Linux 10

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.

Yes, we are using the source from
https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2

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

Debian is a well-known GNU/Linux distribution used by lots of people.

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

Root CA is sharded between a set of trusted people, multiple people have to come together to use it.
Production keys are stored in a HSM.

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 don't use vendor_db

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

Yes

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 ?

We include patches for all of:
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

For the other two CVEs listed here:

• CVE-2020-15705 does not affect our codebase due to other patches (as
  explained back in the boothole days).
• We don't use the shim_lock module, so CVE-2021-3418 does not apply
  to us.

"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

Yes, we add an SBAT entry in all those binaries. Examples:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.02,https://www.gnu.org/software/grub/
grub.debian,1,Debian,grub2,2.02+dfsg1-20+deb10u4,https://tracker.debian.org/pkg/grub2

sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd,1,Firmware update daemon,fwupd,1.2.14,https://github.com/fwupd/fwupd
fwupd.debian,1,Debian,fwupd,1.2.14-1+deb10u1,https://tracker.debian.org/pkg/fwupd

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupdate,1,UEFI firmware update tool,fwupdate,12,https://github.com/rhboot/fwupdate
fwupdate.debian,1,Debian,fwupdate,12-4+deb10u4,https://tracker.debian.org/pkg/fwupdate

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.debian,1,Debian,shim,15.4,https://tracker.debian.org/pkg/shim

All new UEFI binaries that are yet to be built with SBAT support will
follow the agreed SBAT variable pattern and we will add Debian
specific entries for them.

Were your old SHIM hashes provided to Microsoft ?

Yes

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 ?

We revoked the old signer certs that covered those old grub binaries,
and the old signer certs went into Microsoft's updated dbx list at the
time. We switched to a new signer cert at that time.

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 ?

Like many distros, we have our own downstream implementation. We're
working on upstreaming patches, but it's slow going... :-/

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

https://salsa.debian.org/grub-team/grub.git, branch "buster" is the
current version (2.02+dfsg1-20+deb10u4) in Debian Bullseye. It is
derived from the upstream 2.02 release with quite a number of patches
applied - see debian/patches there.

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

It will load fwupdate, fwupd as already mentioned above.

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

None - it will only load a signed, Secureboot Linux

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.

We have added all our previously signed GRUB2 binaries for each
architecture into the vendor_dbx list

How do the launched components prevent execution of unauthenticated code?

• Debian's signed Linux packages have a common set of lockdown patches.
• Debian's signed grub2 packages include common secure boot patches so
  they will only load appropriately signed binaries.
• Debian's signed fwupdate/fwupd packages will not execute other
  binaries

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?

Buster is using Linux 4.19.194-1 (labelled as 4.19.0-17 in Debian). It
has the usual lockdown patches applied - see
https://salsa.debian.org/kernel-team/linux/-/tree/buster/debian/patches/features/all/lockdown
for the current list

What changes were made since your SHIM was last signed?

We added two extra patches as recommended - see the last two listed in README.md

What is the SHA256 hash of your final SHIM binary?

639fb0589296d878fad7414ff68ee4e0f575155e74041923acc89717ef5eeaea  shimia32.efi
6fd6f02abb3ac314d834a9b17f72bb677a09500dc209fbc627aa91d4b85ba9ca  shimx64.efi

[julian-klode]

I reviewed the difference since the last submission, and the extra patches look sensible. I think this is the first submission with the arm64 relocation fixes. Both architectures built reproducibly.

✔️ Accepted.