shim 15.4 + bugfixes for Ubuntu

[xnox]

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-20210421

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/361.patch: kernel errors / invalid config table
  flags. Cherrypick of merged mok: allocate MOK config table as BootServicesData shim#361

• debian/patches/362.patch: mokutil --disable-validation does not
  work. Cherrypick of merged Don't set user_insecure_mode and ignore_db in import_one_mok_state shim#362

• debian/patches/364.patch: fails to boot on older Macs. Cherrypick
  of merged Don't call QueryVariableInfo() on EFI 1.10 machines shim#364

What is the SHA256 hash of your final SHIM binary?

Plain sha256sum, unsigned EFI app:

$ sha256sum 15.4-0ubuntu2/shim*.efi
cf5ee9fe83b386aa11f9eee339d11d99d22c4a1dbe21bce93371f36a9d24aa6b  15.4-0ubuntu2/shimaa64.efi
29be46b65e87e5a3e5bb95173485ddef9759488ea2ca0b2a4b02d0954cedacc5  15.4-0ubuntu2/shimx64.efi

Authenticode hashes:

$ hash-to-efi-sig-list 15.4-0ubuntu2/shimaa64.efi 15.4-0ubuntu2/shimx64.efi /dev/null
HASH IS 2ecc71fe870a6c046c73f2dce867bcc613748fe5d80591670abac1d839c750bc
HASH IS d99c93fcb042dbe52707bbde371c75fcf081dd5b0c88a195d44cc57536f6f521

[xnox]

Ubuntu 21.04 is out today, and we are delaying upgrades to 21.04 until we have this shim signed with these bugfixes.

[Doncuppjr]

Why allow kexec? Is that a feature you really need?

[xnox]

Why allow kexec? Is that a feature you really need?

All distributions with lockdown prohibit regular kexec (KEXEC_LOAD). But all of them support the IMA verified kexec via file load (KEXEC_FILE_LOAD). That's absolutely supported for faster reboots, and to perform partial secureboot kdump.

kexec man page
option -s (--kexec-file-syscall) Specify that the new KEXEC_FILE_LOAD syscall should be used exclusively

[jsetje]

All the major distros support kexec in this fashion. You do have to take care managing certs between versions.

[jsetje]

I am able to reproduce the build and do not see any issues with the request. As soon as there's a second reviewer, I'm happy to mark this as accepted.

[steve-mcintyre]

I can reproduce the x64 build fine, but not the aa64 build. Worried that this is the same problem I've seen in issue #366.

[steve-mcintyre]

Inside the docker build:
Step 11/11 : RUN sha256sum /shim-review/shimaa64.efi /shim/shimaa64.efi
---> Running in aa38f96e6ec3
cf5ee9fe83b386aa11f9eee339d11d99d22c4a1dbe21bce93371f36a9d24aa6b /shim-review/shimaa64.efi
32926e16ae1271b322f9c4e987196b76d7fce1ba096983f895e4969e1b19b481 /shim/shimaa64.efi

[steve-mcintyre]

And diffing hexdumps shows the same story I've seen:

Step 13/14 : RUN diff -u orig build
 ---> Running in 841e13dc1873
--- orig        2021-04-22 20:41:39.000000000 +0000
+++ build       2021-04-22 20:41:42.000000000 +0000
@@ -51106,8 +51106,8 @@
 000c7a10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a30  04 00 00 00 14 00 00 00  03 00 00 00 47 4e 55 00  |............GNU.|
-000c7a40  f4 42 fd 2e 56 29 e5 aa  a6 22 f8 fc e2 c6 56 07  |.B..V)..."....V.|
-000c7a50  25 ff 47 7e 00 00 00 00  00 00 00 00 00 00 00 00  |%.G~............|
+000c7a40  68 4d 2a 93 a3 7e 8c 77  2d a9 28 fa d5 60 b1 4f  |hM*..~.w-.(..`.O|
+000c7a50  fe 20 af 2f 00 00 00 00  00 00 00 00 00 00 00 00  |. ./............|
 000c7a60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a80  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

[steve-mcintyre]

The patches applied here all look fine, and the grub builds etc. are cool too.

But I'm worried about the arm64 build.

[xnox]

And diffing hexdumps shows the same story I've seen:

Step 13/14 : RUN diff -u orig build
 ---> Running in 841e13dc1873
--- orig        2021-04-22 20:41:39.000000000 +0000
+++ build       2021-04-22 20:41:42.000000000 +0000
@@ -51106,8 +51106,8 @@
 000c7a10  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a20  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a30  04 00 00 00 14 00 00 00  03 00 00 00 47 4e 55 00  |............GNU.|
-000c7a40  f4 42 fd 2e 56 29 e5 aa  a6 22 f8 fc e2 c6 56 07  |.B..V)..."....V.|
-000c7a50  25 ff 47 7e 00 00 00 00  00 00 00 00 00 00 00 00  |%.G~............|
+000c7a40  68 4d 2a 93 a3 7e 8c 77  2d a9 28 fa d5 60 b1 4f  |hM*..~.w-.(..`.O|
+000c7a50  fe 20 af 2f 00 00 00 00  00 00 00 00 00 00 00 00  |. ./............|
 000c7a60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a70  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 000c7a80  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

000c7a30 ends with "GNU." which is beginning of the gnu.build-id note.
The next 160 bits (20 hexadecimals) is the sha1 build-id that binutils calculated.

To force binutils to reproduce the same build id, one can do:

sed 's/build-id=sha1/build-id=0xf442fd2e5629e5aaa622f8fce2c6560725ff477e/' -i Make.defaults

Note that on x64 the linker script has build-id in the .so & .so.debug ELF files but does not copy that into the PE/COFF binary, thus there are no such differences on x64.

I also explained this on rhboot/shim#366 (comment)

[jsetje]

While we need to fix the tooling eventually, I don't want to hold this up. That explanation is reasonable.

[haobinnan]

👍