shim 15.4-0ubuntu9 for Ubuntu

[julian-klode]

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:

Canonical Ltd

What product or service is this for:

Ubuntu

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.

Build is based on shim-15.4.tar.gz2
It is located at CanonicalLtd/shim-review@ubuntu-shim-amd64+arm64-20210806

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

Ubuntu is a popular OS.

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

The CA certificate used as VENDOR_CERT is always stored offline, split
using Shamir's Secret Sharing into 7 fragments distributed globally, 3
of which are required to assemble the cert.

Thus we require international travel to be available to assemble it
and issue new certificates.

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 vendor_db.

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

Yes all currently supported kernels have it.
Kernels that do not have it are revoked by vendor_dbx.

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 above CVEs are fixed. Grubs that do not have it fixed are revoked by vendor_dbx.

"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]

shim, fb, mm:
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.ubuntu,1,Ubuntu,shim,15.4-0ubuntu2,https://www.ubuntu.com/

grub:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/
grub.ubuntu,1,Ubuntu,grub2,2.04-1ubuntu45,https://www.ubuntu.com/

fwupd:
sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd,1,Firmware update daemon,fwupd,1.5.8,https://github.com/fwupd/fwupd
fwupd.ubuntu,1,Ubuntu,fwupd,1.5.8-0ubuntu1,https://launchpad.net/ubuntu/+source/fwupd

kernel.efi:
TBD We might start loading kernel.efi in the future which is systemd
sd-boot stub, linux kernel, initrd, cmdline as a single EFI app.

Were your old SHIM hashes provided to Microsoft ?

Yes, all our previously signed shims have been submitted to Microsoft.

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 ?

All vulnerable grubs are revoked by vendor_dbx.

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 ?

grub2 2.04 + lockdown backport + rhboot/canonical like secureboot patches.

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

Building / Publishing
https://launchpad.net/ubuntu/+source/grub2-unsigned - same signed grub binaries for all series

Git managed source code
https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+ref/ubuntu

Note patches debian/patches

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

kernel.efi:
TBD We might start loading kernel.efi in the future which is systemd
sd-boot stub, linux kernel, initrd, cmdline as a single EFI app.

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

GRUB2 may launch Windows Bootmgr on dual boot systems.
Nebooted shim+grub2 may chainloader load shim+grub2 again from disk,
which will verify things again as usual. (https://maas.io usecase).

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.

Adding all vulnerable grubs to vendor_dbx.
Also adding kernels that are vulnerable to ACPI bypass to vendor_dbx too.

How do the launched components prevent execution of unauthenticated code?

fwupd verifies capsule signatures; kernel implements lockdown.

Note that currently kernel does not yet implement correct checking of
MokListXRT for kexec, thus one currently can kexec revoked/old kernels
from the booted good kernel.

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

No, our grub enforces lockdown & uses shim protocol (rhboot linuxefi
sb patches) to verify next component.

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

linux, various versions. They include lockdown patches & ACPI patches,
lockdown is enforced when booted with SecureBoot, config enforces
kernel module signatures under lockdown.

What changes were made since your SHIM was last signed?

New patches since last submission:

• 365.patch - cherry-pick of mok: fix potential buffer overrun in import_mok_state shim#365
• 393-1.patch and 393-2.patch - backport of Fallback to default loader if parsed one does not exist shim#393
• 396.patch - cherry-pick fallback: find_boot_option() needs to return the index for the boot entry in optnum shim#396
• 399-1.patch and 399-2.patch - backport of Don't parse load options if invoked from removable media path shim#399

What is the SHA256 hash of your final SHIM binary?

Plain sha256sum, unsigned EFI app:

$ sha256sum 15.4-0ubuntu*/shim*.efi
8eea86df273688bc6d548c752ace2036632479a073a4314ee2cca91a3251b1aa  15.4-0ubuntu9/shimaa64.efi
7c307799a1173e113f1891af2e604abb948e8de5d98039e72dc1a003b4bdfc79  15.4-0ubuntu9/shimx64.efi

Authenticode hashes:

$ hash-to-efi-sig-list 15.4-0ubuntu9/shim{aa,x}64.efi /dev/null
HASH IS 2e09c1ad4d24d1057b387009d5a6fac2e1a5d85d33ebf18396ed32ee16b72d16
HASH IS dbffd70a2c43fd2c1931f18b8f8c08c5181db15f996f747dfed34def52fad036

[steve-mcintyre]

• amd64 reproduces fine
• arm64 is ok, modulo the expected build ID noise :-/

[steve-mcintyre]

• Patches look OK enough for me.
• No other changes of note.
• Marking as accepted

[haobinnan]

Exception occurred after using patches 393-1 / 393-2 / 399-1 / 399-2. And I got following messages after replacing \EFI\Microsoft\Boot\bootmgfw.efi with shimx64.efi:
Falled to open \EFI\Microsoft\Boot\S - Invalid Parameter
Failed to load image \EFI\Microsoft\Boot\S: Invalid Parameter
start_image() returned Invalid Parameter, falling back to default loader

[julian-klode]

@haobinnan hey, did you mean that this fixed your issue? Because \S being passed in boot options if you use bcdedit in Windows is well known, and this patch series addresses the issue as you can see in the last line of the output, by falling back to the default.

[haobinnan]

Thank you for your quick reply! The issue is not fixed. I got these errors after adding after using patches 393-1 / 393-2 / 399-1 / 399-2 (these errors do not appear if I do not use these patches). I'd like to know if there is any way to use these patches without getting these errors?
@julian-klode

[julian-klode]

I'm confused. Without the patches, the error should appear as well, and the boot should fail. With the patches, the errors should still be displayed but the boot should continue.

You could try just some of the patches and see which one triggers the error for you - 399-2 needs 399-1, but otherwise all patches are independent.