Tracking issue for the Secure Boot work that follows #957 and #960. It exists because the question that started it — "can we use a shim to get FOG's own bzImage trusted out of the box, the way abotzung/foguefi appears to?" — has a definite answer that is worth writing down once instead of rediscovering.
The answer: no, and foguefi does not do it either
Microsoft signs a shim as a unit, with its vendor CA compiled in. ipxe/shim trusts exactly one thing — the iPXE Secure Boot CA — and derives its second stage from its own filename. There is no downstream hook, by design; a shim that loaded any binary calling itself iPXE would be worthless. Nothing FOG builds can satisfy it.
foguefi sidesteps this rather than solving it: it downloads Canonical's pre-signed shimx64.efi + grubx64.efi + Ubuntu's signed kernel, and carries FOG's logic in an unsigned initrd. There is no FOS kernel in that chain, iPXE is dropped entirely, and the project is archived (Feb 2026) with unfinished docs.
Booting a custombzImage under Secure Boot therefore always requires FOG's certificate to be trusted somewhere — MOK or firmware db.
Verified artifact inventory
Read directly from the PE certificate tables, because a wrong assumption here already cost one round of rework:
| Binary | Source | Signature |
|---|
ipxe-shimx64.efi | ipxe/shim release ipxe-16.1 | MS UEFI CA 2011 + 2023 (two WIN_CERTIFICATE entries) |
x86_64-sb/shimx64.efi | ipxeboot.tar.gz | MS UEFI CA 2011 only |
x86_64-sb/snponly.efi | ipxeboot.tar.gz | iPXE Secure Boot Intermediate G1A |
x86_64-sb/ipxe.efi | ipxeboot.tar.gz | iPXE Secure Boot Intermediate G1A |
arm64-sb/snponly.efi | ipxeboot.tar.gz | iPXE Secure Boot Intermediate G1A |
x86_64/snponly.efi | ipxeboot.tar.gz | unsigned — outside -sb/, do not use |
Two things worth keeping in mind:
- The shim picks its second stage by stripping
-shim from its own filename. The tarball ships ipxe-shim.efi and snponly-shim.efi as two symlinks to a single shimx64.efi for exactly this reason. Renaming does not disturb the signature, which covers file contents. - Take the shim from the
ipxe/shim release, not the tarball — only the standalone build carries the 2023 signature, which is what newer hardware needs.
1. Make the MOK route turnkey — PRs open
Signing was manual and quietly came undone on every upgrade. Now automated.
Known limit, stated in both the code and the guide: the sudo helper protects the key, not the act of signing. Anyone who can run code as the web server can have a kernel of their choosing signed; they cannot walk off with the key. Closing that would mean verifying the staged image against a known-good hash first.
2. A distro-signed grub chain as an alternate boot file — DROPPED
A signed snponly.efi already exists, so this has no reason to be built.
The grub path had exactly one justification: ipxe/ipxe#1776, on the belief that the only signed x86-64 iPXE binary was an all-drivers build that takes the NIC from the firmware and hangs on some hardware. That belief was wrong — it came from looking in the release's -sb.usb disk image, which carries only ipxe.efi. The signed snponly.efi ships in ipxeboot.tar.gz, for arm64 as well as x86_64. #1776 is closed as not planned, correctly.
Since the grub chain never bought out-of-the-box trust either — MOK enrolment was still required — nothing remains in its column. #961 and #84 now stage and document snponly.efi, which is the same driver model FOG already serves every other client, so a Secure Boot machine stops being a special case.
Recorded so nobody re-derives it: a MOK-signed custom kernel would have booted via Canonical's signed chain (shim validates against MokListRT as well as its vendor cert), and grub's efinet uses firmware SNP handles rather than its own NIC drivers. The approach was sound; it is simply no longer needed.
3. FOG's own Microsoft-signed shim — long game
The only route to genuinely out-of-the-box trust. rhboot/shim-review wants an EV certificate from the Microsoft Hardware Dev Center, HSM/smartcard key custody, a security contact with a PGP key, a build from the shim 16.1 tarball with a frozen-toolchain Dockerfile, a vendor SBAT entry, and a signed kernel that enforces lockdown. Volunteer-run review, ~2–3 months minimum, permanent CVE/hash-revocation duty after.
Worth recording: fleet-scale db enrolment is mostly a dead end
db/dbx are authenticated variables whose updates must be signed by a private PK or KEK, and on OEM hardware that key is Microsoft's — so there is no owner-usable path without setup/custom mode. Dell genuinely exposes programmable custom-mode PK/KEK/db import via Dell Command | Configure and iDRAC. Lenovo supports clearing PK into setup mode, but whether Think BIOS Config can push cert blobs unattended is unconfirmed. HP consumer lines have no enrolment mode at all; HP commercial is unconfirmed.
Tracking issue for the Secure Boot work that follows #957 and #960. It exists because the question that started it — "can we use a shim to get FOG's own
bzImagetrusted out of the box, the way abotzung/foguefi appears to?" — has a definite answer that is worth writing down once instead of rediscovering.The answer: no, and foguefi does not do it either
Microsoft signs a shim as a unit, with its vendor CA compiled in.
ipxe/shimtrusts exactly one thing — the iPXE Secure Boot CA — and derives its second stage from its own filename. There is no downstream hook, by design; a shim that loaded any binary calling itself iPXE would be worthless. Nothing FOG builds can satisfy it.foguefi sidesteps this rather than solving it: it downloads Canonical's pre-signed
shimx64.efi+grubx64.efi+ Ubuntu's signed kernel, and carries FOG's logic in an unsigned initrd. There is no FOS kernel in that chain, iPXE is dropped entirely, and the project is archived (Feb 2026) with unfinished docs.Booting a custom
bzImageunder Secure Boot therefore always requires FOG's certificate to be trusted somewhere — MOK or firmwaredb.Verified artifact inventory
Read directly from the PE certificate tables, because a wrong assumption here already cost one round of rework:
ipxe-shimx64.efiipxe/shimreleaseipxe-16.1WIN_CERTIFICATEentries)x86_64-sb/shimx64.efiipxeboot.tar.gzx86_64-sb/snponly.efiipxeboot.tar.gzx86_64-sb/ipxe.efiipxeboot.tar.gzarm64-sb/snponly.efiipxeboot.tar.gzx86_64/snponly.efiipxeboot.tar.gz-sb/, do not useTwo things worth keeping in mind:
-shimfrom its own filename. The tarball shipsipxe-shim.efiandsnponly-shim.efias two symlinks to a singleshimx64.efifor exactly this reason. Renaming does not disturb the signature, which covers file contents.ipxe/shimrelease, not the tarball — only the standalone build carries the 2023 signature, which is what newer hardware needs.1. Make the MOK route turnkey — PRs open
Signing was manual and quietly came undone on every upgrade. Now automated.
--secure-boot-stage; commented DHCP classbuild.sh --sign-key/--sign-certKnown limit, stated in both the code and the guide: the sudo helper protects the key, not the act of signing. Anyone who can run code as the web server can have a kernel of their choosing signed; they cannot walk off with the key. Closing that would mean verifying the staged image against a known-good hash first.
2.
A distro-signed grub chain as an alternate boot file— DROPPEDA signed
snponly.efialready exists, so this has no reason to be built.The grub path had exactly one justification: ipxe/ipxe#1776, on the belief that the only signed x86-64 iPXE binary was an all-drivers build that takes the NIC from the firmware and hangs on some hardware. That belief was wrong — it came from looking in the release's
-sb.usbdisk image, which carries onlyipxe.efi. The signedsnponly.efiships inipxeboot.tar.gz, for arm64 as well as x86_64. #1776 is closed as not planned, correctly.Since the grub chain never bought out-of-the-box trust either — MOK enrolment was still required — nothing remains in its column. #961 and #84 now stage and document
snponly.efi, which is the same driver model FOG already serves every other client, so a Secure Boot machine stops being a special case.Recorded so nobody re-derives it: a MOK-signed custom kernel would have booted via Canonical's signed chain (shim validates against
MokListRTas well as its vendor cert), and grub'sefinetuses firmware SNP handles rather than its own NIC drivers. The approach was sound; it is simply no longer needed.3. FOG's own Microsoft-signed shim — long game
The only route to genuinely out-of-the-box trust.
rhboot/shim-reviewwants an EV certificate from the Microsoft Hardware Dev Center, HSM/smartcard key custody, a security contact with a PGP key, a build from the shim 16.1 tarball with a frozen-toolchain Dockerfile, a vendor SBAT entry, and a signed kernel that enforces lockdown. Volunteer-run review, ~2–3 months minimum, permanent CVE/hash-revocation duty after.bzImage+ a network-supplied command line + an unsigned ext2 initrd. Lockdown in integrity mode is the accepted mitigation and shim-review does not literally mandate a UKI, but for a payload shaped like this a reviewer will push hard. If FOG cannot move to a UKI, the application probably is not winnable — and the lockdown patch below buys nothing on its own.security_lock_kernel_down()is not in mainline, nor isefi_enabled(EFI_SECURE_BOOT). Seedocs/adr/0009in Build the lockdown LSM into the FOS kernel, without activating it fos#131 for the hook point and a smaller single-file alternative.Worth recording: fleet-scale
dbenrolment is mostly a dead enddb/dbxare authenticated variables whose updates must be signed by a private PK or KEK, and on OEM hardware that key is Microsoft's — so there is no owner-usable path without setup/custom mode. Dell genuinely exposes programmable custom-mode PK/KEK/db import via Dell Command | Configure and iDRAC. Lenovo supports clearing PK into setup mode, but whether Think BIOS Config can push cert blobs unattended is unconfirmed. HP consumer lines have no enrolment mode at all; HP commercial is unconfirmed.