shim-15.8 for opsi

[uibmz]

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 )
  not used
• 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
  no extra patches used
• 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/opsi-org/shim-review/tree/opsi-shim-x86_64-20240215

---

What is the SHA256 hash of your final SHIM binary?

---

141cd6016ba62586059e2ab453d2d07a2e1b97516b7838dace3da71bdcdd58c5

---

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

---

#310
#245
#29

[uibmz]

Updated the tag to be reviewed.
NX Patch Removed
Updated README.md
Updated shimx64.efi to be signed
updated build.log

[aronowski]

Please, update the issue, so it reflects the current shim 15.8.

[uibmz]

Hi @aronowski the issue is updated as you requested.
The new tag contains a shim-15.8 build

[aronowski]

Thank you. Although the GitHub issue title still mentions 15.7 - I'd update it to prevent a reviewer from accidentally closing it.

[uibmz]

Done, thanks for the quick hint

[aronowski]

Reviewing.

The application looks alright apart from only one error I managed to spot: the checksum provided in the current README doesn't match the one the current binary has.
The current one is 141cd6016ba62586059e2ab453d2d07a2e1b97516b7838dace3da71bdcdd58c5. And this is properly reflected in the GitHub issue's first post.

---

Notes:

There is shim.opsi,4, which I suppose is for historical reasons as there already was a lower number, which got bumped, and we're about to document the proper numbering method. - OK

No NX support, as the kernel 6.6 is not considered NX-ready. - OK

[uibmz]

THank you for your first view on our issue @aronowski

We just updated the README.md with the proper hash. This ssems to have been forgotten when updating the issue to 15.8.

The tag links is also updated to reflect this change.

[aronowski]

Awesome!
Let's wait for another official review and let me wish you all the best!

[steve-mcintyre]

Hi! Mostly looks great, I just have couple of questions for you.

Review of Shim 15.8 for opsi: opsi-shim-x86_64-20240215

OK

• Contact verification already done (shim-15.6 for opsi #245) - OK
• shim build reproduces here - OK
• Builds from 15.8 upstream, with no patches applied - OK
• NX bit not set - OK
• Includes a CA key expiring in 2032 - OK
• Kernel modules signed with ephemeral key - OK
• SBAT bumped for shim and GRUB to revoke old binaries, and older
  hashes should be blocked - OK
• GRUB2 from upstream 2.12-rc1 with all CVE fixes included - OK
• Iist of grub modules is fine (for now!) - OK
  • we may be asking for a more minimal set of modules in future. ntfs
    can be problamatic
• Shim only loads grub, no other binaries - OK
• kernel 6.6.x with lockdown patches - OK
• SBAT data looks fine for shim and grub - OK

Issues / queries

• I'm not 100% clear on your key management. You say you have a separate encrypted machine, with access controlled by hardware token. Could you expand on that some more please?
  • How are binaries transferred to the signing machine?
  • What's the role of the hardware token? (And what hw token are you using?)
• Do you have any additional grub patches at all?
  • And I assume you're looking at moving to the 2.12 release soon?

[uibmz]

Hi @steve-mcintyre

Thanks for your review so far.

About your issues/queries
The token we use is a Hardware Token provided by our EV Certificate Issuer (Globalsign). Our signing key for the Secure Boot binaries is stored on this token.
This token is only used on this one machine. We run automated build processes for Grub2 binaries and Linux Kernel builds. After the automated build is complete the artifacts are published on an internal only file server.
We then download those files on the sign machine, enter the token password and sign the files with the aforementioned Secure Boot keys. Those signed files are then uploaded to the file server again. Afterwards an automated process takes over to create a package with those signed files, along with other files.
I hope this cleared things up :)

As for the grub, when the issue was opened initially we were using grub2-2.12-rc1. Internally we have already switched the grub2 buildprocess to use grub2-12. Right now we use vanilla grub2-2.12 but we are going to add patches from the official SUSE patchset in the near future, but we will first look deeper in what we need

Regards

[steve-mcintyre]

Hi @steve-mcintyre

Thanks for your review so far.

Thanks for the quick response!

About your issues/queries The token we use is a Hardware Token provided by our EV Certificate Issuer (Globalsign). Our signing key for the Secure Boot binaries is stored on this token. This token is only used on this one machine. We run automated build processes for Grub2 binaries and Linux Kernel builds. After the automated build is complete the artifacts are published on an internal only file server. We then download those files on the sign machine, enter the token password and sign the files with the aforementioned Secure Boot keys. Those signed files are then uploaded to the file server again. Afterwards an automated process takes over to create a package with those signed files, along with other files. I hope this cleared things up :)

Hmmm. So you have an embedded CA cert in your shim, then you're using
an EV cert for signing the binaries? That sounds slightly odd, I'll be
honest. Or are you just re-using an existing hardware token (which
came the EV cert for Microsoft submission maybe?) ?

As for the grub, when the issue was opened initially we were using grub2-2.12-rc1. Internally we have already switched the grub2 buildprocess to use grub2-12. Right now we use vanilla grub2-2.12 but we are going to add patches from the official SUSE patchset in the near future, but we will first look deeper in what we need

OK, cool. :-)

[uibmz]

Hi @steve-mcintyre

Hmmm. So you have an embedded CA cert in your shim, then you're using an EV cert for signing the binaries? That sounds slightly odd, I'll be honest. Or are you just re-using an existing hardware token (which came the EV cert for Microsoft submission maybe?) ?

The hardware token contains multiple certificates. Our EV certificate and our Secure Boot certificate/keys. The EV certificate itself was used to initially sign the testfile for Microsoft when joining the Microsoft Developers Program for the UEFI submissions and is NOT used to sign Kernel or Grub2 images. The Secure Boot keys are used to sign our Kernel and Grub2 images. Those Secure Boot keys match the embedded CA Cert in our shim submission.
We added the Secure Boot keys on the hardware token to make sure we use current standard technology to secure our keys.

[steve-mcintyre]

Thanks for explaining, that's much clearer now.

[steve-mcintyre]

I think you're all good here!