SLES Expanded Support platform 8

[jsegitz]

Confirm the following are included in your repo, checking each box:

• 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 to 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 is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/jsegitz/shim-review/tree/SUSE-liberty-15.8-20240415

---

What is the SHA256 hash of your final SHIM binary?

---

Output from sha256sum:

$ sha256sum shimia32.efi

7b94d13b6d9a45e040f6b47cdf9774e8633010d60f7e5a1e962a458740dcfb58 shimia32.efi

$ sha256sum shimx64.efi

8375d94dfd60ca75be6490740d48bd3fd1688650d15bc5da2e9a44e808496c9a shimx64.efi

Output from pesign:

$ pesign --hash --padding --in=shimia32.efi

hash: b7a6529881db7ecd80634b4fa3cf0bfe6b7c66b779b8ea26b6ec7e3ff08dbab8

$ pesign --hash --padding --in=shimx64.efi

hash: bcc42e50c81159a7d6e278ebbff1f5168c07f37579d2d33ad65bc247c1f431d1

---

What is the link to your previous shim review request (if any, otherwise N/A)?

---

#114

---

If no security contacts have changed since verification, what is the link to your request, where they've been verified (if any, otherwise N/A)?

---

I don't think we (Marcus Meissner, Johannes Segitz) have had our contacts verified. But I've submitted multiple
submissions that were accepted with these security contacts. Right answer probably still is
N/A

[jsegitz]

updated grub2 sources and SBAT entries

[jsegitz]

I had to update the Dockerfile as shim didn't build anymore

[THS-on]

Review of SUSE-liberty-15.8-20240415

• SUSE is a well known Linux vendor
• They need a Shim to boot their own GRUB2 builds etc.
• Security contacts haven't changed. Here the same situation as with Debian. @steve-mcintyre do you want to send new verification emails or not?

Shim

• Based on 15.8
• NX is disabled
• keys are stored in a custom build HSM (fine see comment here: Shim 15.7 for SUSE expanded support 8 #318 (comment))
• Certificate matches the organization
  • Serial: 1
  • Subject: CN = SLE Expanded Support Secure Boot CA, C = DE, L = Nuremberg, O = SUSE Linux Products GmbH, emailAddress = res-maintenance@suse.de
  • Valid till: Oct 25 15:54:45 2037 GMT (22 years)
  • Certificate is CA certificate and KeyUsage/DigitalSignature is set
  • 2048 bit (still fine as discussed in previous meeting)
• Builds are reproducible

#34 0.319 8375d94dfd60ca75be6490740d48bd3fd1688650d15bc5da2e9a44e808496c9a  /usr/share/shim/15.8-2.el8/x64/shimx64.efi
#34 0.324 8375d94dfd60ca75be6490740d48bd3fd1688650d15bc5da2e9a44e808496c9a  /shimx64.efi
#34 0.329 7b94d13b6d9a45e040f6b47cdf9774e8633010d60f7e5a1e962a458740dcfb58  /usr/share/shim/15.8-2.el8/ia32/shimia32.efi
#34 0.334 7b94d13b6d9a45e040f6b47cdf9774e8633010d60f7e5a1e962a458740dcfb58  /shimia32.efi

GRUB2

• Based on RHEL package (2.02-148)
• Does not include ntfs patches, as they are not signing the ntfs module
  • Note: the next shim will revoke the grub SBAT < 4 and Debian (+ some derivatives) are already doing that
  • This is consistent to the RHEL submission shim 15.8 for RHEL 8 x64 #374
• In Shim 15.7 for SUSE expanded support 8 #318 the grub.sles was set to 3 without there being a version bump the the upstream SBAT. This is not good.
• Ideally someone with more experience in RHEL like distributions should also have a look at it

fwupd

• SBAT looks fine

Kernel

• Based on kernel-4.18.0-513.9.1.el8_9 from RHEL
• ephemeral key signing is used
• Includes lockdown patches

Questions and Notes

• Ideally someone with more RHEL like implementation should take a look at the GRUB2 and Kernel package
• Please clarify the SBAT entry for GRUB2 and which different GRUB2 builds were signed. Generally the SBAT versions should only increase
• The 15.7 submission contained a patch to revoke the grub.sles < 3 binaries. Why is this dropped from this version?

[steve-mcintyre]

Contact verification ongoing in #419

[steve-mcintyre]

Contact verification completed in #419

[steve-mcintyre]

@jsegitz do you have answers for @THS-on 's questions please?

[jsegitz]

Thanks for the review @THS-on

@steve-mcintyre yes sorry, round trip with the engineers took a while, already had the tab open writing the answer when you asked :)

As for your questions:

• For 15.8, we followed RHEL's SBAT, plus a rotation of signature has been made on SLES ES8, banning all old grubs from booting.
• 15.7 was never signed by Microsoft and didn't get into production. The patch is not required anymore. All those excluded GRUBs from 15.7 have general SBAT values < 3 which means they will be revoked now with the current submission.

[steve-mcintyre]

Needs a second review

[THS-on]

@jsegitz thank you for the answers.

For 15.8, we followed RHEL's SBAT, plus a rotation of signature has been made on SLES ES8, banning all old grubs from booting.

Just note that, the RHEL based GRUBS are mostly currently on upstream SBAT level 3 and RHEL level 2. None of those get revoked in 15.8. This is planned for the next 15.9 release. See https://github.com/rhboot/shim/blob/main/SbatLevel_Variable.txt

15.7 was never signed by Microsoft and didn't get into production. The patch is not required anymore. All those excluded GRUBs from 15.7 have general SBAT values < 3 which means they will be revoked now with the current submission.

Ah I see. Yeah makes sense then to drop this. But just to clarify you in the last submission you already had GRUB2 versions with SBAT level 3 (https://github.com/jsegitz/shim-review/blob/be73155fb67deb0c349166956f2e0a9eba968762/README.md?plain=1#L246-L247), do you just mean the ones that were signed incorrectly had an SBAT level < 3?

I still would recommend not to decrease the grub.sles SBAT, because that makes it harder to track what GRUBs it actually revokes with which other entries present.

[jsegitz]

Correct. Just those incorrectly signed GRUBs had SBAT level < 3.

We'd like to keep the GRUB2 just in this submission as is, if possible, and apply the proposed workflow to the future versions of GRUB2 and track the history no matter if GRUBs were actually delivered to end-users or not.

[THS-on]

We'd like to keep the GRUB2 just in this submission as is, if possible, and apply the proposed workflow to the future versions of GRUB2 and track the history no matter if GRUBs were actually delivered to end-users or not.

Fine for me. I would just bump it then directly to 4 in the next release, so there is no confusion. My questions have been answered. Needs one more review.

[steve-mcintyre]

Please update the tag here to match what you're asking us to review. AFAICS the tag SUSE-liberty-15.8-20240415 is a couple of commits behind HEAD on SUSE-liberty-15.8-20240415_branch

[steve-mcintyre]

Going ahead using what's on the branch, I'm having problems with the Dockerfile:

...
#7 [ 3/30] RUN dnf -y install gcc-8.5.0-20.el8 binutils-2.30-123.el8 make-4.2.1-11.el8 elfutils-libelf-devel-0.189-3.el8
#7 sha256:35787e50929513965065b992227ed7f2e50981c92dfcc4582dbad94b2c0b78aa
#7 0.303 CentOS Stream 8 - AppStream                     1.2 kB/s |  38  B     00:00    
#7 0.308 Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
#7 ERROR: executor failed running [/bin/sh -c dnf -y install gcc-8.5.0-20.el8 binutils-2.30-123.el8 make-4.2.1-11.el8 elfutils-libelf-devel-0.189-3.el8]: exit code: 1
------
 > [ 3/30] RUN dnf -y install gcc-8.5.0-20.el8 binutils-2.30-123.el8 make-4.2.1-11.el8 elfutils-libelf-devel-0.189-3.el8:
------
executor failed running [/bin/sh -c dnf -y install gcc-8.5.0-20.el8 binutils-2.30-123.el8 make-4.2.1-11.el8 elfutils-libelf-devel-0.189-3.el8]: exit code: 1

[jsegitz]

Please update the tag here to match what you're asking us to review. AFAICS the tag SUSE-liberty-15.8-20240415 is a couple of commits behind HEAD on SUSE-liberty-15.8-20240415_branch

sorry, that seems to be too hard for my brain to remember to also push the tag ...

I pushed it and also fixed they build issue you saw

[jsegitz]

Is there anything I can do to help with the review? I fear that it'll break again if we wait to long

[evilteq]

Everything seems ok.
I was able to build docker and reproduced binaries fine.

[steve-mcintyre]

Review of Shim 15.8 for SLES Expanded Support platform 8, SUSE-liberty-15.8-20240415

Good

General

• Contact verification already done before - OK
• Keys in an HSM - OK

Shim

• shim builds reproduce here - OK

8375d94dfd60ca75be6490740d48bd3fd1688650d15bc5da2e9a44e808496c9a  /usr/share/shim/15.8-2.el8/x64/shimx64.efi
8375d94dfd60ca75be6490740d48bd3fd1688650d15bc5da2e9a44e808496c9a  /shimx64.efi
7b94d13b6d9a45e040f6b47cdf9774e8633010d60f7e5a1e962a458740dcfb58  /usr/share/shim/15.8-2.el8/ia32/shimia32.efi
7b94d13b6d9a45e040f6b47cdf9774e8633010d60f7e5a1e962a458740dcfb58  /shimia32.efi

• Builds from 15.8 upstream with no patches - OK
• NX bit not set in both shim binaries - OK
• Includes a 2k RSA CA key expiring in 2037 - OK

  Signature Algorithm: sha256WithRSAEncryption
  Issuer: CN = SLE Expanded Support Secure Boot CA, C = DE, L = Nuremberg, O = SUSE Linux Products GmbH, emailAddress = res-maintenance@suse.de
  Validity
    Not Before: Nov 30 15:54:45 2015 GMT
    Not After : Oct 25 15:54:45 2037 GMT
  Subject: CN = SLE Expanded Support Secure Boot CA, C = DE, L = Nuremberg, O = SUSE Linux Products GmbH, emailAddress = res-maintenance@suse.de

• SBAT data looks fine for shim - OK
• Shim loads grub and fwupd - OK

GRUB

• Revocations for older binaries look fine.
• SBAT data looks less good for GRUB, but I see the conversation with
  @THS-on already about that.
• Reasonable list of grub modules - OK

Linux

• kernel-4.18.0-513.9.1.el8_9 based on publicly available RHEL source
  with lockdown patches. - OK
• Kernel modules signed with ephemeral key - OK

fwupd

• SBAT data is OK (ish!) - see below...

Queries and tweaks

• Your fwupd SBAT data is correct for the bits that matter (the first
  two fields), but you claim version 1.3 from upstream yet 1.7.8 for
  the sles version. Please fix this for future submissions!

[steve-mcintyre]

I think we have enough good reviews, accepting.

[jsegitz]

thank you very much, will sent it to MS right away

[jsegitz]

got signed by MS