Shim 15.8 for Cisco

[vasudevluthra]

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

• [x] completed README.md file with the necessary information
• [x] shim.efi to be signed
• [x] public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• [x] binaries, for which hashes are added to vendor_db ( if you use vendor_db and have hashes allow-listed ) N/A
• [x] any extra patches to shim via your own git tree or as files N/A
• [x] any extra patches to grub via your own git tree or as files N/A
• [x] build logs
• [x] 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/cisco/sto-uefi-secure-bootloader/releases/tag/cisco-shim-x86_64-20240415

Updated tag after modifying Dockerfile to use release tarball instead of git branch https://github.com/cisco/sto-uefi-secure-bootloader/releases/tag/cisco-shim-x86_64-20240613

---

What is the SHA256 hash of your final SHIM binary?

---

SHA2-256(shimx64.efi)= 7d8bce770e56b615ba2b7021f56611fdb50948ebac4693fb0952e89d3c9e0258

---

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

---

https://github.com/rhboot/shim-review/issues/354

https://github.com/rhboot/shim-review/issues/126

https://github.com/rhboot/shim-review/issues/37 (accepted)

---

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)?

---

https://github.com/rhboot/shim-review/issues/354#issuecomment-1883345036

[es-fabricemarie]

I'm not an official reviewer, but I just want to help reduce the work load of official reviewers.

• dockerfile pulls from official shim git repo directly, branch 15.8:

  RUN git clone -b "15.8" https://github.com/rhboot/shim.git /shim-build

• no patch applied, straight build from source + company cert + company sbat csv
• build is reproducible
• shim shasum matches: 7d8bce770e56b615ba2b7021f56611fdb50948ebac4693fb0952e89d3c9e0258 shimx64.efi
• certificate:
  • certificate valid for 79 years apparently. Seems too long
  • RSA, 2048 bit
  • Subject: O = Cisco, OU = Perseus, CN = Virtual UEFI SubCA V3
  • Issuer: OU = Pavo, O = Cisco, CN = Virtual UEFI Root CA V2

• shim sbat section is appropriate.

  objcopy -j .sbat -O binary shimx64.efi /dev/stdout

  sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
  shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim
  shim.cisco,1,Cisco,shim,15.8,psirt@cisco.com

• NX bit disabled

  objdump -p shimx64.efi  | grep DllCharacteristics

  DllCharacteristics      00000000

• signing keys are in HSM
• author uses unmodiied upstream Ubuntu and AlmaLinux grub packages.
  • Might need to check version/patch-level for sbat

[vasudevluthra]

Hello reviewers @steve-mcintyre @aronowski, it would be really helpful if you could kindly review our submission for the shim review. Our last two shim review submission #354 and #126 got closed before being approved and we have been trying to get the shim review completed for a while. A lot of teams at Cisco are dependent on this shim and we would really appreciate if you could kindly review our submission.

[aronowski]

On 2024.05.15 12:18:44, vasudevluthra wrote:

Hello reviewers @steve-mcintyre @aronowski, it would be really helpful if you could kindly review our submission for the shim review.

Yes, but we do have limited resources ourselves. It would also be really helpful if we got some help in this matter as well. There are some applications, where it would come in handy for people to do some community work and help us review these.

Our last two shim review submission #354 and #126 got closed before being approved and we have been trying to get the shim review completed for a while.

I know that feeling. I myself have been trying for about 2 years.

A lot of teams at Cisco are dependent on this shim and we would really appreciate if you could kindly review our submission.

Should I help and write an application to convince the managers, that investing a certain amount of the current budget will help in the long term?

-- Reply to this email directly or view it on GitHub: https://github.com/rhboot/shim-review/issues/411#issuecomment-2113294795 You are receiving this because you were mentioned.

Message ID: @.***>

[THS-on]

Review of cisco-shim-x86_64-20240415

• Cisco Systems is a well known vendor
• Needs to boot their own kernels and has an old signed shim
• Contacts were verified before

Shim

• Based on 15.8 without patches. As mentioned above the Dockerfile builds directly from the git branch. Please use the release tarball instead (because the source is the same it should produce the same shim, but that is more stable and easier to check).
• NX bit disabled
• Includes CA certificate
  • Not code signing attribute set (still ok)
  • RSA 2048bit
  • Subject: O = Cisco, OU = Perseus, CN = Virtual UEFI SubCA V3
  • Valid till: Oct 22 15:26:16 2099 GMT (that's very long as mentioned, normal is more around 30 years)
  • SBAT looks fine
  • Shim is reproducible

    7d8bce770e56b615ba2b7021f56611fdb50948ebac4693fb0952e89d3c9e0258  shimx64.efi

GRUB2

• Upstream is Almalinux and Canonical
• Not clear which Ubuntu GRUB2 is used. For example the one in main is 2.06-2ubuntu7 and very old. That one GRUB2 will be revoked by pretty much any new Shim. The one in updates, 2.06-2ubuntu14.4 ,is patched up until SBAT level 4.
• Modules list not included

Kernel

• Upstream is Almalinux and Canonical
• Ephemeral key signing is not used (still ok)

Notes and Questions

• Please explicitly state in the submission that the NX bit is disabled
• Please switch to use the release tarball in the Dockerfile for simpler review. Similarly also output the hashes directly
• I assume that your CA is not used currently. We currently have no strict policies for CAs, but with RSA 2048 bit keys maybe limit the validity to 2030 for new CAs. @steve-mcintyre any opinions here?
• Please link to the exact Ubuntu GRUB2 that you use and which modules (or a way how we can find it)
• How do you make sure that older kernel modules cannot be loaded on newer kernels?
• Are you planning on building UKIs?
• Are you planning on using fwupd or systemd-boot?

[steve-mcintyre]

• I assume that your CA is not used currently. We currently have no strict policies for CAs, but with RSA 2048 bit keys maybe limit the validity to 2030 for new CAs. @steve-mcintyre any opinions here?

There's still a worry about using keys larger than 2048 bits of RSA; older firmware versions on older machines may not work. We're hoping to get some testing done to give us better data here. For now, we have to allow 2048-bit RSA.

[vasudevluthra]

Hello reviewers @THS-on and @steve-mcintyre, thank you for reviewing our submission. Based on your comments, we have made changes to the Dockerfile to use the release tarball instead of the git branch. The updated tag is https://github.com/cisco/sto-uefi-secure-bootloader/releases/tag/cisco-shim-x86_64-20240613 , I have also updated the tag in the checklist for this issue.

In addition, to address your questions,

• Yes, the NX bit is disabled, as mentioned in the submission, there is no change to default NX bit setting. We tested it on our target x86 architecture with entire shim/grub bootchain
• We have updated our Dockerfile to use the tarball instead of the git repo
• For the comment on the CAs and validity, we manage our expiry more granularly at the End Entity level. We prefer to keep the CAs at a longer time period to avoid issues with CA expiry.
• The exact version of the Ubuntu GRUB2 we use is 2.06-2ubuntu14.4 (grub-efi-amd64-signed_1.187.6+2.06-2ubuntu14.4_amd64.deb. We update to use the latest upstream version).
• We do not plan to build UKIs.
• We do not plan to use fwupd or system-boot.

@aronowski We have started some conversations internally with the goal to be more involved in contributing to the shim community.

[THS-on]

Hi @vasudevluthra thank you for the updates and answering the questions. Because you don't use ephemeral key signing for the Linux kernel can provide an answer to from above:

• How do you make sure that older kernel modules cannot be loaded on newer kernels?

[vasudevluthra]

Hi @THS-on thank you for your comment. We use our own embedded cert in the kernel to verify our signatures. The kernel can be delivered with new embedded keys as needed that do not allow loading older modules.

[THS-on]

@vasudevluthra thanks for the clarification. Ideally you would switch the cert every time, but I think its fine for now. @steve-mcintyre what do you think?

[NeilHanlon]

Note I am not an official reviewer, this is an ‘extra’ review

Review of cisco-shim-x86_64-20240613

• Vendor: Cisco Systems
• Well Known: Yes
• Contact Status: Verified previously

Shim

• Version: 15.8
• Source: from github. shasum valid.
• NX Bit Status: Disabled
• Includes CA Certificate: Yes
• Code Signing Attribute: No
• RSA Key Length: 2048
• Subject: O = Cisco, OU = Perseus, CN = Virtual UEFI SubCA V3
• Validity: Valid until 2099
  • confirmed policy at Cisco manages sub-cert lifecycle
• Stored in HSM
• SBAT Status: Good
• Reproducibility: Reproduces

  sha256sum install/shimx64.efi
  7d8bce770e56b615ba2b7021f56611fdb50948ebac4693fb0952e89d3c9e0258  install/shimx64.efi

GRUB2

• Upstream Sources: not provided; union of Ubuntu + AlmaLinux
• Ubuntu GRUB2 Version: 2.06-2
• AlmaLinux GRUB2 Version: 2.06-61 (9), 2.02-158 (8)
• SBAT Level: N/A
• Included Modules: not provided

Kernel

• Upstream Sources: supports booting Ubuntu and AlmaLinux, both accepted vendors
• Ephemeral Key Signing: No. HSM-backed.

Notes and Questions

• Are non-ephemeral kernel/kmod signing keys provided via HSM OK? @steve-mcintyre
• Otherwise, this submission looks good.

[SherifNagy]

@vasudevluthra just one question, what do you mean by We use upstreams distros for grub since we are not rebuilding it. I assume you still building it to sign the grub with your own keys, or are you loading upstream keys?

Can you rub objcopy on the efi and paste here the SBAT entries from your grub*.efi?

[vasudevluthra]

Hi @SherifNagy, thank you for your review. We only rebuild the kernels with additional hardening, which requires us to sign with our own key. We do resign GRUB with the same key but we have no need to rebuild GRUB.

This is the SBAT entry for the grub:

[steve-mcintyre]

Checking the existing reviews, I think this looks good. Accepted!

[vasudevluthra]

Thanks a lot for the review and acceptance @steve-mcintyre! We really appreciate it.