Shim 16.0 for Proxmox Bookworm-based

[Fabian-Gruenbichler]

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/Fabian-Gruenbichler/shim-review/tree/proxmox-shim-16.0-amd64-20250328

---

What is the SHA256 hash of your final SHIM binary?

---

d6fee8ef8276a2b9ed6a5e47f71bd29e55a96786dfe29d74dbbc6660ef3a2fe6

---

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

---

#414
#330

---

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

---

#330

[aronowski]

Looks good, although I'll need to wait until the code at rhboot/shim#739 is confirmed to be safe, before treating my own review as positive. Feel free to ping me, once that's done, and I'll change this issue's labels.

Just a minor nitpick: all the checkboxes in the original post should be checked. One of them is unchecked.

[lorddoskias]

• Build reproduces

    #25 [22/24] RUN sha256sum /efi-boot-shim/shim*.efi /shim-review/$(basename /shim/shim*.efi)
    #25 0.155 d6fee8ef8276a2b9ed6a5e47f71bd29e55a96786dfe29d74dbbc6660ef3a2fe6  /efi-boot-shim/shimx64.efi
    #25 0.158 d6fee8ef8276a2b9ed6a5e47f71bd29e55a96786dfe29d74dbbc6660ef3a2fe6  /shim-review/shimx64.efi

• Shim 16 sources are used and the sum matches.

• Keys are managed by a FIPS certified HSM

• Shim looks sane

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.proxmox,1,Proxmox,shim,16.0,https://git.proxmox.com/?p=efi-boot-shim.git

• Certificate is legit and has the CA extension

        Issuer: C = AT, ST = Vienna, L = Vienna, O = Proxmox Server Solutions GmbH, CN = Secure Boot CA, emailAddress = office@proxmox.com
        Validity
            Not Before: Mar  6 13:51:34 2023 GMT
            Not After : Mar  3 13:51:34 2033 GMT
        Subject: C = AT, ST = Vienna, L = Vienna, O = Proxmox Server Solutions GmbH, CN = Secure Boot CA, emailAddress = office@proxmox.com

  X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE

Although this is not visible from the Dockerfile as the rules for building are really under the debian directory and executed via the dpkg-buildpackage

• Grub modules look sane
• Ephemeral key is used for module signing

[jsetje]

If you intend to use shim 16 with UKIs please carefully consider if this issue impact your use cases:

rhboot/shim#741

If it does, you may want to hold off for a fix.

[Fabian-Gruenbichler]

If you intend to use shim 16 with UKIs please carefully consider if this issue impact your use cases:

rhboot/shim#741

If it does, you may want to hold off for a fix.

we don't plan on signing UKIs or using this shim with any UKIs at the moment

[Fabian-Gruenbichler]

Looks good, although I'll need to wait until the code at rhboot/shim#739 is confirmed to be safe, before treating my own review as positive. Feel free to ping me, once that's done, and I'll change this issue's labels.

Just a minor nitpick: all the checkboxes in the original post should be checked. One of them is unchecked.

the PR got merged now!

[SherifNagy]

@Fabian-Gruenbichler do you still need this review after pushing #476 forward?

[Fabian-Gruenbichler]

yes, these are two different shim builds for different release series. we will still support the Bookworm based one for at least a year going forward!

while both shims are very similar, they are built with different toolchain and base system versions so they are not identical.

[SherifNagy]

@Fabian-Gruenbichler how can you make sure that NTFS module of grub isn't used if secureboot is enabled based in this revert commit https://git.proxmox.com/?p=grub2.git;a=commit;h=a7a440dc5425b03e0b754920d3b502dba6ebbd19

[Fabian-Gruenbichler]

@SherifNagy

thank you for asking that question. NTFS was supposed to be disabled entirely under lockdown because of this patch (same treeish), which was (intentionally) not reverted:

https://git.proxmox.com/?p=grub2.git;a=blob;f=debian/patches/cve_2025_02_multiple/0181-fs-Disable-many-filesystems-under-lockdown.patch;h=2141991f0412b9cde78641da616044741aa59640;hb=a7a440dc5425b03e0b754920d3b502dba6ebbd19#l210

unfortunately, that was not 100% effective for our Bookworm based Grub builds, which was discovered while re-checking for the answer here. the pre-built monolithic EFI binary used for SecureBoot enabled setups still contained the NTFS module, and the disabling at module init time was not effective unless the module was actively unloaded first before attempting to use it.

this issue is specific to our Bookworm variant of Grub, because

• it contains the revert of the NTFS fixes with regressions called out above
• it contains NTFS in the list of modules to be included in the signed Grub image
• it is still based on 2.06 with Debian's implementation of booting

none of the following seem to be affected based on our analysis:

• Ubuntu Jammy (which has the same 2.06 + revert of regression-inducing NTFS fixes baseline, but other patches that avoid the issue)
• newer still supported Ubuntu releases (which are already on 2.12)
• stock Debian Bookworm (2.06, but without that set of CVE fixes in the first place, and thus also no revert - we will inform the Debian Grub maintainers because if they update to include those fixes, they might be tempted to pull in the revert from Ubuntu as well)
• Debian Trixie or our upcoming Trixie-based releases (based on 2.12)

as a mitigation, we've removed the NTFS module from our monolithic images, and released fixed packages with our vendor-suffixed Grub SBAT level bumped to 2:

https://forum.proxmox.com/threads/proxmox-virtual-environment-security-advisories.149331/page-2#post-782751
https://git.proxmox.com/?p=grub2.git;a=commitdiff;h=0006f4cb96fda7c8f97148ff88c2d079703ab653
https://git.proxmox.com/?p=grub2.git;a=commitdiff;h=3e5615a9d36a0909e0a2ac0b0447dc5310b5d3ad

a new shim-review tag with updated information was pushed as well:
https://github.com/Fabian-Gruenbichler/shim-review/tree/proxmox-shim-16.0-amd64-20250710

let us know if there is anything else we should do regarding this issue. one thing we contemplated is bumping the LATEST policy in our two pending shim submissions, but that would entail deciding on a date, which probably requires coordination here? for now, we've shipped an updated latest policy covering the affected Grub binaries via our certmule-based revocations.efi file, so that users can opt into revoking trust in those binaries without waiting for an updated shim.

[SherifNagy]

@Fabian-Gruenbichler thanks for the clarification, would you please open a PR here https://github.com/rhboot/shim so the older SBAT entry gets included and revoked?

I will get back to look at this new tag https://github.com/Fabian-Gruenbichler/shim-review/tree/proxmox-shim-16.0-amd64-20250710 later this week