shim 15.4-0ubuntu5 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-20210616

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:

• debian/patches/372.patch: do not fail on out of resources when mirroring
  on non-secure systems. Cherrypick of Relax the check for import_mok_state() shim#372

• debian/patches/378.patch: Fixes for exiting shim, caused crashes and failure
  to exit grub and return (it would reboot instead). Cherrypick of
  Don't unhook ExitBootServices when EBS protection is disabled shim#378

• debian/patches/ubuntu-no-addend-vendor-dbx.patch: Stop addending the vendor
  dbx to the MokListX, ours is too large. Our kernels don't read it anyway,
  and new ones that will can just embed it themselves.

What is the SHA256 hash of your final SHIM binary?

Plain sha256sum, unsigned EFI app:

$ sha256sum 15.4-0ubuntu5/shim*.efi
04c4ec2e3f8e4cbfe694fb9a51f7cda56136e30957d662a5af6d70eeb16dcae2  15.4-0ubuntu5/shimaa64.efi
b0bd3023fade3e3d1601c88792064ef8113125a51e00909f0231a05485391985  15.4-0ubuntu5/shimx64.efi

Authenticode hashes:

$ hash-to-efi-sig-list 15.4-0ubuntu5/shim{aa,x}64.efi /dev/null
HASH IS b546b63dcd649d26faf2f0e6bbbf9e052a8e017e6b704bd766ad4cf2c490438e
HASH IS f3a4673ed94c4f00e2222066191ca6fe3d1d411f5ce5d748a0c180f5243a5ab3

[julian-klode]

The arm64 build is still not entirely reproducible as last time in #167

We will still need yet another shim with fixed boot loader option parsing for fwupd; this one we need for closing Ubuntu 16.04 mostly and to be able to have people upgrade to 21.04 on Apple hardware, and hardware without much EFI variable storage space. We did not make much progress in rhboot/shim#374, rhboot/shim#379, or rhboot/shim#380 yet; but need to unblock those other bits :(

[julian-klode]

debian/patches/372.patch is rhboot/shim#372 of course, not 364, sorry.

[julian-klode]

We need this shim such that we can enable upgrades from groovy to hirsute for everyone, and build our last xenial images. Would be great to get a review. Don't want to entangle the load option parsing changes in the next shim with those things.

[steve-mcintyre]

@julian-klode I've updated bits of my system so I can run your docker build - yay!

Less yay - I'm seeing an issue with reproducing the amd64 shim:

Step 15/15 : RUN diff -u orig build
 ---> Running in 8526bbeda336
--- orig        2021-06-16 08:25:26.000000000 +0000
+++ build       2021-06-16 08:25:28.000000000 +0000
@@ -11,7 +11,7 @@
 000000a0  00 9a 06 00 00 00 00 00  00 20 02 00 00 20 02 00  |......... ... ..|
 000000b0  00 00 00 00 00 00 00 00  00 10 00 00 00 02 00 00  |................|
 000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-000000d0  00 30 0d 00 00 04 00 00  cb 50 0f 00 0a 00 00 00  |.0.......P......|
+000000d0  00 30 0d 00 00 04 00 00  cb 4e 0f 00 0a 00 00 00  |.0.......N......|
 000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00000100  00 00 00 00 10 00 00 00  00 00 00 00 00 00 00 00  |................|
@@ -24,27 +24,27 @@
 00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00000180  00 00 00 00 00 00 00 00  2f 34 00 00 00 00 00 00  |......../4......|
 00000190  a4 cc 01 00 00 50 00 00  00 ce 01 00 00 04 00 00  |.....P..........|
-000001a0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 40 40  |............@.@@|
+000001a0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 40  |............@..@|
 000001b0  2e 74 65 78 74 00 00 00  87 ea 05 00 00 20 02 00  |.text........ ..|
 000001c0  00 ec 05 00 00 d2 01 00  00 00 00 00 00 00 00 00  |................|
-000001d0  00 00 00 00 20 00 30 60  2e 72 65 6c 6f 63 00 00  |.... .0`.reloc..|
+000001d0  00 00 00 00 20 00 00 60  2e 72 65 6c 6f 63 00 00  |.... ..`.reloc..|
 000001e0  0a 00 00 00 00 10 08 00  00 02 00 00 00 be 07 00  |................|
-000001f0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 10 42  |............@..B|
+000001f0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 42  |............@..B|
 00000200  2f 31 34 00 00 00 00 00  6b 00 00 00 00 30 08 00  |/14.....k....0..|
 00000210  00 02 00 00 00 c0 07 00  00 00 00 00 00 00 00 00  |................|
-00000220  00 00 00 00 40 00 60 c0  2e 64 61 74 61 00 00 00  |....@.`..data...|
+00000220  00 00 00 00 40 00 00 c0  2e 64 61 74 61 00 00 00  |....@....data...|
 00000230  b4 bf 02 00 00 40 08 00  00 c0 02 00 00 c2 07 00  |.....@..........|
-00000240  00 00 00 00 00 00 00 00  00 00 00 00 40 00 60 c0  |............@.`.|
+00000240  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 c0  |............@...|
 00000250  2f 32 36 00 00 00 00 00  b0 4f 00 00 00 00 0b 00  |/26......O......|
 00000260  00 50 00 00 00 82 0a 00  00 00 00 00 00 00 00 00  |.P..............|
-00000270  00 00 00 00 40 00 30 40  2e 64 79 6e 61 6d 69 63  |....@.0@.dynamic|
+00000270  00 00 00 00 40 00 00 40  2e 64 79 6e 61 6d 69 63  |....@..@.dynamic|
 00000280  00 01 00 00 00 50 0b 00  00 02 00 00 00 d2 0a 00  |.....P..........|
-00000290  00 00 00 00 00 00 00 00  00 00 00 00 40 00 40 c0  |............@.@.|
+00000290  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 c0  |............@...|
 000002a0  2e 72 65 6c 61 00 00 00  d0 b2 01 00 00 60 0b 00  |.rela........`..|
 000002b0  00 b4 01 00 00 d4 0a 00  00 00 00 00 00 00 00 00  |................|
-000002c0  00 00 00 00 40 00 40 40  2e 73 62 61 74 00 00 00  |....@.@@.sbat...|
+000002c0  00 00 00 00 40 00 00 40  2e 73 62 61 74 00 00 00  |....@..@.sbat...|
 000002d0  c3 00 00 00 00 20 0d 00  00 02 00 00 00 88 0c 00  |..... ..........|
-000002e0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 10 40  |............@..@|
+000002e0  00 00 00 00 00 00 00 00  00 00 00 00 40 00 00 40  |............@..@|
 000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00000300  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
The command '/bin/sh -c diff -u orig build' returned a non-zero code: 1

Any ideas?

[julian-klode]

I figured it's rhboot/shim#366 - we still have not made arm64 builds reproducible yet. I could not reproduce it either, but I'm not sure if my diff was smaller. I think the compiler got upgraded in impish as well 3 days ago which might screw it up a bit more?

[steve-mcintyre]

arg, sorry - missed the important stuff off the beginning of the log there. This is amd64!

 ---> d23736e66959
Step 13/15 : RUN hexdump -Cv /shim-review/shimx64.efi > orig
 ---> Running in 945e96657946
Removing intermediate container 945e96657946
 ---> b5c04c830b11
Step 14/15 : RUN hexdump -Cv /shim/shimx64.efi > build
 ---> Running in e17bcccda9dd
Removing intermediate container e17bcccda9dd
 ---> 02e56119ad58

[julian-klode]

Yes, it no longer reproduces now due to new compiler. Reproducible builds are haard, sigh

[julian-klode]

Updated to shim 15.4-0ubuntu5, built in hirsute, that is reproducible now, except for the build id issue on arm64:

--- orig        2021-06-16 13:17:17.000000000 +0000
+++ build       2021-06-16 13:17:23.000000000 +0000
@@ -51103,8 +51103,8 @@
 000c79e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c79f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a00  04 00 00 00 14 00 00 00  03 00 00 00 47 4e 55 00  |............GNU.|
-000c7a10  b7 95 b2 de 60 41 fb bc  b8 8f 9c 0a eb 33 d5 77  |....`A.......3.w|
-000c7a20  51 64 2d fa 00 00 00 00  00 00 00 00 00 00 00 00  |Qd-.............|
+000c7a10  4a 4b 87 c9 2d 9d 82 13  8e f7 82 3d c8 56 92 3b  |JK..-......=.V.;|
+000c7a20  9f 62 7f 69 00 00 00 00  00 00 00 00 00 00 00 00  |.b.i............|
 000c7a30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a40  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a50  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[steve-mcintyre]

trying again here

[steve-mcintyre]

• amd64 reproduces ok
• arm64 shim reproduces ok, modulo the issues we've already identified
• patches are all sane, upstream is good
• SBAT data looks fine
• embedded CA cert is fine, same as seen before
• kernel and grub look ok

accepted

[julian-klode]

We got signed binary back, so closing