shim 15.8 for SUSE Enterprise Linux

[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-SLES-shim-x86_aarch64-20240229

---

What is the SHA256 hash of your final SHIM binary?

---

x86_64:
pesign: f327bfe0e31193974df9fa68b621a2c87d154ef2986059ce16fc6d0bd7537a96 shim-sles.efi
sha256sum: bf24a19e3bd5ca535b0815be9e49b36b835a9f36310ed5b3e5f87959a52b87e2 shim-sles.efi

aarch64:
pesign: 8bfe4fc6a7506d82a4efdd39ecac04ef0ab6f65d9ac3514d803462a7b4ae7fcf shim-sles.efi
sha256sum: 5f3c747130027da84c47256a6d089b6cb1c923a3517d31c8703e360c9f2832c6 shim-sles.efi

---

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

---

#301

[jsegitz]

Updated the tag to indicted the current SLES service pack (SP5 instead of SP4)

[MuthuvelKuppusamy]

Not able to reproduce the build,

[jsegitz]

seems like the architecture variable is not set (line 206 in the README.md). Please try
podman build --build-arg ARCHITECTURE=x86_64 -t sles_shim:15.8 .

[aronowski]

Reviewing.

---

The x86_64 shim binary does reproduce and has the checksum bf24a19e3bd5ca535b0815be9e49b36b835a9f36310ed5b3e5f87959a52b87e2. It matches the GitHub issue original post and the mention in README.md. 👍

However, the binary attached in the repository has a different checksum (50b38af2d6508cbcc57924e97940f450a07b85410c3212f97897a4eae7a189db). Why?

---

*******************************************************************************
### Do you use an ephemeral key for signing kernel modules?
### If not, please describe how you ensure that one kernel build does not load modules built for another kernel.
*******************************************************************************
We don't use ephemeral keys. There's no mechanism to ensure that kernel modules are not loaded by another kernel.

I'm worried about this, as it may be a dealbreaker as of today. I'd be happy to try things out on my end and recompile the system kernel if needed, but asking first:
Would there be issues in integrating an emphemeral key usage to the kernel build process or using another method, like those hinted at in the "Ephemeral keys for kernel modules and the alternatives" paragraph in this comment?

Note for myself: leaving the v5.14 kernel module signing document here in case I need it later.

---

Minor curiosity: the shim SBAT entry written in the application 's README.md has the vendor_url "mail:[email protected]", but it looks like the binaries* use a slightly different one, i.e. "mail:[email protected]".

* checked by dumping the .sbat section from shim-sles_aarch64.efi.

---

In order to reproduce the aarch64 build on an x86_64 machine, I ran this command:

$ time docker buildx build --build-arg ARCHITECTURE=aarch64 --platform linux/arm64 -t suse-sles-shim-x86_aarch64-20240229-arm64 --progress=plain .

The binary looks alright! 👍

[jsegitz]

Thank you for the review. The shim binary is the one from our build service, not of the local (or container build). That was my error, sorry. The pesign hash has been fine, but the sha256sum not. I uploaded the proper shim binary in jsegitz@8519f8d and updated the tag

[jsegitz]

Ephemeral keys: We work with vendors to make their kernel modules work on our operating system. Recompiling every module for every new kernel would be problematic for us. I'll raise this with our kernel team, but even if it's possible (and I'm not so sure about this) it would need quite some time.

SBAT entries email: These addresses are reaching the same team, but I'll see that we unify this. Thanks for the note

[jsegitz]

If there's anything we can do to help this move quickly please don't hesitate to tell us. Thanks

[jsetje]

I'm not spotting any remaining issues here.

[jsegitz]

thank you very much for the review!