shim-15.4 + fixes (ia32, x64) for OS ALT (Bazalt Svobodnoe Programmnoe Obespechenie, OOO)

[realnickel]

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/realnickel/shim-review/tree/BaseALT-shim15.4-ia32-x64-20210511
• 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
  https://github.com/realnickel/shim-review/blob/BaseALT-shim15.4-ia32-x64-20210511/docker_reproduce.sh
  https://github.com/realnickel/shim-review/blob/BaseALT-shim15.4-ia32-x64-20210511/Dockerfile

What organization or people are asking to have this signed:

Basealt Ltd. (Bazalt Svobodnoe Programmnoe Obespechenie, OOO)
https://www.basealt.ru

What product or service is this for:

OS ALT
https://getalt.org/en/
https://www.basealt.ru/go/downloads/

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.

We use 15.4 shim (https://github.com/rhboot/shim/releases/tag/15.4) +
1bea91ba Fix a broken file header on ia32 (PR #357)

all patches from #165 to address
critical issues

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 linux distribution supporting Secure Boot

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

Access to server used to sign binaries is restricted physically.
Only few trusted persons have sign authority.

Do you use EV certificates as embedded certificates in the SHIM?

No EV certs, but selfsigned altlinux-ca.cer is embedded

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

No

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 ?

Yes

"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

SBAT for shim:

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.altlinux,1,ALT Linux,shim,15.4-alt2,http://git.altlinux.org/gears/s/shim.git

SBAT for grub:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.06-rc1,https://www.gnu.org/software/grub/
grub.altlinux,1,ALT Linux,grub,2.06-alt1.rc1,http://git.altlinux.org/gears/g/grub.git

SBAT for fwupd has the same style

sbat,1,UEFI shim,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
fwupd,1,Firmware update daemon,fwupd,1.5.9,https://github.com/fwupd/fwupd
fwupd.altlinux,1,ALT Linux,fwupd,1.5.9-alt1,http://git.altlinux.org/gears/f/fwupd.git

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 ?

Yes

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 ?

Downstream RHEL/Fedora/Debian/Canonical like implementation

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

upstream grub-2.06-rc1 including patches for all currently discussed security issues;
also there are some SB patches from Fedora and other patches listed in repository's grub_patches subdir

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

It also launches fwupd-1.5.9-alt1

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

It doesn't

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 are switching to a new certificate

How do the launched components prevent execution of unauthenticated code?

GRUB and kernel are patched to enforce Secure Boot.

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?

Linux Kernel:
5.4 (std-def: standard longterm kernel for stable branches),
5.10 (std-def: standard longterm kernel for unstable branch),
http://git.altlinux.org/gears/k/kernel-image-std-def.git
5.11 (un-def: more modern than std-def and with forced preemption enabled),
http://git.altlinux.org/gears/k/kernel-image-un-def.git?p=kernel-image-un-def.git;a=summary

What changes were made since your SHIM was last signed?

Upstream version update (15 -> 15.4 + fixes)

What is the SHA256 hash of your final SHIM binary?

00f59c23d70369ebe4c6f1f74928e094f5b15e155da4f484c4e6d2946ded8c90 shimia32.efi

4ed7d10389810632198d9c227296e46b222c16daf0122d0f17b5cbe52c18cd72 shimx64.efi

[Doncuppjr]

Step 9/12 : ADD ./hsh-sandbox.tar /home/builder
ADD failed: stat /var/lib/docker/tmp/docker-builder610958066/hsh-sandbox.tar: no such file or directory
docker: Error response from daemon: unable to find user builder: no matching entries in passwd file.
ERRO[0000] error waiting for container: context canceled
Error: No such container:path: shim_rebuild:/home/builder/shim/log
Error: No such container:path: shim_rebuild:/home/builder/shim/.gear/shim.spec
Error: No such container:path: shim_rebuild:/tmp/.private/builder/hsh-sandbox/sisyphus-x86_64/hasher/chroot/usr/src/RPM/BUILD/shim-15.4/build-ia32/shimia32.efi
Error: No such container:path: shim_rebuild:/tmp/.private/builder/hsh-sandbox/sisyphus-x86_64/hasher/chroot/usr/src/RPM/BUILD/shim-15.4/build-x64/shimx64.efi
sha256sum: ./build/shimia32.efi: No such file or directory
sha256sum: ./build/shimx64.efi: No such file or directory
shim_rebuild

[Doncuppjr]

Successfully built e78a647d44ff
Successfully tagged alt:sisyphus
/bin/bash: /home/builder/hsh-sandbox/sisyphus-x86_64/compile: No such file or directory

[realnickel]

Step 9/12 : ADD ./hsh-sandbox.tar /home/builder
ADD failed: stat /var/lib/docker/tmp/docker-builder610958066/hsh-sandbox.tar: no such file or directory

@Doncuppjr, thanks for pointing this out. There was a stupid filename mismatch between shell script and Dockerfile.
It should be fixed now.
Will you please give it an another try?

[Doncuppjr]

I can confirm that this builds and reproduces the submitted hashes. 10 year cert, which I also did, so Idk.

[Doncuppjr]

.sbat section looks good

[realnickel]

@julian-klode, @martinezjavier, @jsetje are there any missings in our submission preventing it from being reviewed further?
I'd like to mention that
1bea91ba Fix a broken file header on ia32 (PR #357)
was applied here from the moment of submission.
Our tests on ia32 platform with self-signed cert showed that binary became bootable after patch application.

[Doncuppjr]

I think we’re waiting for verification that you wanted to continue without patches for 362 and 364. 362 could be a big issue for some.

[realnickel]

I think we’re waiting for verification that you wanted to continue without patches for 362 and 364. 362 could be a big issue for some.

If this is the only blocker for approval I can resubmit with those patches, if delay would be shorter.
Anyway nothing is said by now about grub and it's patches and remaining points of review. Are all of them OK?

[steve-mcintyre]

I can reproduce the builds OK
Grub patches look sane enough - please push the custom stuff upstream when you can (yes, we're all sucking at this!)
Reasonable-looking CA key included. I'd be happier if you said you had an HSM in use for key storage there. IIRC Microsoft ask for this too.
You'll need to update fwupd to 1.5.9 to fix the SBAT data it builds - we've all been bitten by a bug there

Also, as suggested by @Doncuppjr you should probably check on the list of issues referenced in #165. I'd expect you will probably want to pull in the patches referenced there too. Adding a "question" label for that. Happy to mark things accepted once you respond on that front.

Finally: I'm trying to steer shim development discussions into being more open, and we have a mailing list now: https://lists.einval.com/cgi-bin/mailman/listinfo/efi

[realnickel]

@steve-mcintyre, thank you for the review.
Sorry for late reply, I was AFK for a while.

You'll need to update fwupd to 1.5.9 to fix the SBAT data it builds - we've all been bitten by a bug there

fwupd version is already 1.5.9, dot separator for the vendor specific package name is in SBAT section now.

Also, as suggested by @Doncuppjr you should probably check on the list of issues referenced in #165. I'd expect you will probably want to pull in the patches referenced there too. Adding a "question" label for that. Happy to mark things accepted once you respond on that front.

I applied all patches from #165 to new build.

My shim-review repository was updated accordingly.
Would you please look at it one more time?

[steve-mcintyre]

I'm struggling to reproduce your builds using the docker_reproduce.sh script. The binaries in your review branch are:

00f59c23d70369ebe4c6f1f74928e094f5b15e155da4f484c4e6d2946ded8c90  shimia32.efi
4ed7d10389810632198d9c227296e46b222c16daf0122d0f17b5cbe52c18cd72  shimx64.efi

which matches what you have in your text here. However, despite doing a git pull and re-running the script, I think I'm still reproducing your older builds:

$ sha256sum build/*.efi
8472ae9ba2bb9f686b9adaa2cbd9c0b49ef799a94b4f7f1184bcace9188a51e1  build/shimia32.efi
74602cab1f56e346993ca86b1f58a6705ce00e74fe6af5d78432d556083091ae  build/shimx64.efi

Do I need to do something special to clean up before re-running, maybe?

[realnickel]

Sorry for inconvenience, @steve-mcintyre!
You may probably have cached images of Docker layers left after first rebuild.

$ sudo docker image ls
REPOSITORY   TAG        IMAGE ID       CREATED        SIZE
alt          sisyphus   ad8e637bfc86   10 days ago    578MB
alt          <none>     04643c8d43c5   3 months ago   108MB

Please try to remove cached images and dependent containers before running the script.
I will try to modify our script to remove sensitive cached artifacts before new reproduction session to prevent this in future.

[steve-mcintyre]

• OK - I killed everything and restarted from scratch and now I can reproduce OK now. Yay Docker :-/
• SBAT looks ok, etc.
• Patches look sane

Marking as accepted.

[realnickel]

Submission was signed.
Thanks to everyone involved, especially @Doncuppjr and @steve-mcintyre.