Verify the Secure Boot chain on real hardware (shim to signed iPXE to signed FOS kernel)

[mastacontrola]

Is your feature request related to a problem? Please describe.

#957 decided what FOG does about Secure Boot: nothing out of the box, opt-in and documented. The guide is merged at fog-docs secure-boot-signing.

What has not happened is anyone booting that chain on real hardware. Every individual link is upstream-supported and the artefacts have been inspected, but the end-to-end path is unproven and the guide says so in its Known limits. This issue tracks closing that gap.

Describe the solution you'd like

Boot a UEFI machine with Secure Boot on, through:

firmware  →  ipxe-shimx64.efi        (Microsoft UEFI CA 2011 + 2023, from ipxe/shim)
          →  ipxe.efi                (iPXE Secure Boot Intermediate G1A, extracted
                                      from ipxe-x86_64-sb.usb at EFI/BOOT/IPXE.EFI)
          →  autoexec.ipxe           (FOG's boot logic, served over TFTP)
          →  bzImage                 (signed locally, key enrolled via MOK)

and confirm it reaches the FOG menu and completes a deploy.

Specific things to check, because they are the parts most likely to be wrong:

1. Where autoexec.ipxe has to live. iPXE's efi_autoexec_network() calls imgacquire() with a bare filename, which resolves against cwuri — the directory the .efi was loaded from, not the TFTP root. So a stock ipxe.efi sitting at /tftpboot/ipxe.efi looks for /tftpboot/autoexec.ipxe, which FOG does not currently create; FOG only ships /tftpboot/autoexec/autoexec.ipxe. Confirm what cwuri actually resolves to when the binary is reached via shim rather than directly — the shim is loaded first, and whether cwuri follows the shim's path or iPXE's is worth observing rather than assuming.
2. Whether the installer should place autoexec.ipxe at the TFTP root, or whether the shim and ipxe.efi should live in their own subdirectory with a copy beside them. Falls out of (1).
3. That MOK enrolment via mmx64.efi works from a PXE-booted shim, not just from an installed distro.
4. HTTPS is expected to fail and should be confirmed as failing cleanly rather than mysteriously — stock ipxe.efi has no FOG CA compiled in. See Feature Request: Support for External Intermediate CA (e.g., Smallstep step-ca) #794.
5. CONFIG_EFI_STUB=y on the FOS kernel — under Secure Boot the kernel is loaded by the firmware's loader, not iPXE's.

Additional context

Verified while filing this, so it does not need re-deriving:

Binary	PE certificate table	Signer
ipxe-shimx64.efi (ipxe/shim ipxe-16.1)	19232 bytes	Microsoft UEFI CA 2011 and 2023
EFI/BOOT/BOOTX64.EFI (inside -sb.usb)	9728 bytes	Microsoft UEFI CA 2011 only
EFI/BOOT/IPXE.EFI (inside -sb.usb)	8552 bytes	iPXE Secure Boot Intermediate G1A
FOG's /tftpboot/ipxe.efi	none	—
FOG's /tftpboot/autoexec/snponly.efi	none	—

FOG's binaries are unsigned by construction (EMBED=ipxescript plus CERT=/TRUST=), which is why the stock upstream binary has to be used here.

Refs #957, #794, #959

[mastacontrola]

Results: the Secure Boot signature chain is verified

Tested on VirtualBox 7.2.14 (EFI, Secure Boot enabled via VBoxManage modifynvram, Microsoft certificates enrolled into db with enrollmssignatures, Oracle PK via enrollorclpk). Files served from /tftpboot/secureboot/.

The chain works end to end:

firmware (Secure Boot ON, MS certs in db)
  -> secureboot/ipxe-shimx64.efi    accepted by firmware
  -> secureboot/ipxe.efi            accepted by shim
  -> secureboot/autoexec.ipxe       fetched and loaded ("autoexec.ipxe... ok")

And the negative case proves the trust boundary is real. Serving the identical ipxe.efi without the shim, Secure Boot still on: TFTP delivered the file four times and the firmware refused to execute it every time. iPXE's code-signing certificate is inside the shim's vendor certificate, not in firmware db — so the shim is genuinely required, not decoration.

Test	Signatures	Outcome
shim -> ipxe.efi -> autoexec.ipxe, SB on	all verified	all three loaded
ipxe.efi direct, SB on	firmware rejected	never executes
ipxe.efi direct, SB off	n/a	loads, then hangs (see below)

Where autoexec.ipxe is fetched from — answered

Point 1 of this issue asked where iPXE looks. Observed directly:

autoexec.ipxe...  Not found
/autoexec.ipxe... Not found

iPXE tries two paths — first relative to cwuri (the directory the running .efi was downloaded from), then absolute at the TFTP root. The root fallback was not something I expected; it means the hard link the installer now creates at /tftpboot/autoexec.ipxe (working-1.6 8980ff114, dev-branch 3c0b4ce37) is consumed for binaries booted from any subdirectory, not just the root. Confirmed in the TFTP log once the link existed:

Client 10.20.0.64 finished ipxe.efi
Client 10.20.0.64 finished autoexec.ipxe

Point 1's sub-question — whether cwuri follows the shim or iPXE — was malformed. A shim loads its second stage from its own directory, so the two are necessarily co-located.

What does NOT work, and it is not Secure Boot

After the chain completes, iPXE hangs during device initialisation: no banner, no DHCP, no further TFTP. Isolated with three binaries on the same VM:

Binary	Driver set	Built by	Result
autoexec/snponly.efi	SNP only	FOG	boots to the FOG menu
ipxe.efi	all drivers	FOG	hangs in device init
secureboot/ipxe.efi	all drivers	upstream, signed	hangs in device init

Two independently built all-drivers binaries fail identically while the SNP-only build succeeds, and the failure is unchanged with Secure Boot off and the shim removed. So this is the driver set, not signing, not the shim, and not a corrupt file.

ipxe.efi carries iPXE's native NIC drivers and on EFI disconnects the firmware's UEFI network driver to bind its own — which is why it dies immediately after initialising devices. snponly.efi has no native drivers and rides the firmware's Simple Network Protocol, so nothing is disconnected. This is the long-standing reason FOG ships snponly.efi as the default UEFI boot file.

Most likely VirtualBox-specific. ipxe.efi is upstream's flagship binary and works broadly on physical hardware; VBox's emulated e1000 plus its EFI driver is a much narrower path. Stated as inference, not fact — what was demonstrated is that it fails on VBox e1000, not that it succeeds elsewhere.

The real gap

Upstream's Secure Boot release ships only the all-drivers ipxe.efi (inside ipxe-x86_64-sb.usb at EFI/BOOT/IPXE.EFI). There is no signed snponly variant. On any machine where native takeover fails — which is the entire reason snponly exists — Secure Boot currently has no working option, because you cannot build your own and keep the signature. Raised upstream as a packaging request.

Also found: SELinux

in.tftpd was denied read on files copied into /tftpboot/secureboot/ — cp gives them default_t instead of tftpdir_t. The test box is permissive so it worked anyway; on an enforcing system this presents as a confusing "file not found". Any procedure needs restorecon -Rv /tftpboot afterwards. Added to the guide.

Still open

• Stage 2, a MOK-signed bzImage actually booting, is untestable here until device init works.
• Retest on physical hardware, where the all-drivers binary is expected to initialise normally.

[mastacontrola]

Full chain now reaches the FOG menu with Secure Boot on — using the signed snponly.efi

First, a correction to my previous comment

That comment said the hang was a dead end because upstream ships only an all-drivers signed binary. That was wrong. A signed snponly.efi already exists — it is just not in the -sb.usb/.iso images I had been looking in. It ships in the release's ipxeboot.tar.gz:

ipxeboot/x86_64-sb/ipxe.efi              signed, all drivers
ipxeboot/x86_64-sb/snponly.efi           signed, SNP only
ipxeboot/x86_64-sb/shimx64.efi           MS UEFI CA 2011 only
ipxeboot/x86_64-sb/ipxe-shim.efi     ->  shimx64.efi
ipxeboot/x86_64-sb/snponly-shim.efi  ->  shimx64.efi

Same set under arm64-sb/. Reading the PE certificate tables, snponly.efi carries the identical signer as ipxe.efi — the iPXE Secure Boot Automatic Code Signing G1A chain — and strings confirms it holds no native NIC drivers (no 82540em; ipxe.efi has it). Per-commit Secure Boot builds signed with the test certificate are also at https://boot.ipxe.org/x86_64-efi-sb/.

I filed ipxe/ipxe#1776 asking upstream for something that already existed. It was closed the same day. Apologies for the noise — the mistake was generalising from one release asset without checking the others.

The retest

Same VirtualBox 7.2.14 VM that hung before, same emulated Intel 82540EM, Secure Boot on, Microsoft certificates in db. Only the served files changed:

• secureboot/snponly.efi — from ipxeboot.tar.gz, x86_64-sb/
• secureboot/snponly-shimx64.efi — a copy of ipxe-shimx64.efi from ipxe/shim ipxe-16.1 (dual-signed 2011 + 2023), renamed

in.tftpd -v, unedited:

RRQ from 10.20.0.50 filename secureboot/snponly-shimx64.efi
Client 10.20.0.50 finished secureboot/snponly-shimx64.efi
RRQ from 10.20.0.50 filename secureboot/revocations_sku.efi        File not found
RRQ from 10.20.0.50 filename secureboot/revocations_sbat.efi       File not found
RRQ from 10.20.0.50 filename secureboot/shim_certificate_0.efi     File not found
RRQ from 10.20.0.50 filename secureboot/snponly.efi
Client 10.20.0.50 finished secureboot/snponly.efi
RRQ from 10.20.0.50 filename secureboot/autoexec.ipxe
Client 10.20.0.50 finished secureboot/autoexec.ipxe
   ... iPXE DHCPs (dnsmasq logs "tags: UEFI, ipxe") ...
RRQ from 10.20.0.50 filename default.ipxe
Client 10.20.0.50 finished default.ipxe
   ... chain http://<server>/fog/service/ipxe/boot.php##params ...

and the FOG boot menu renders — "Host is NOT registered!", the full entry list. That text is generated by boot.php, so the HTTP hop completed too.

The three File not found lines are shim probing for optional revocation and certificate files. They are harmless.

The hang is gone. It was the driver set, exactly as the previous comment concluded — snponly binds only the firmware's UEFI network protocol instead of taking the NIC over, so there is nothing to fail. Worth noting this is also the same driver model FOG already serves every other UEFI client, so Secure Boot machines stop being a special case.

How the shim finds snponly.efi

Not obvious, and worth recording. The shim picks its second stage from its own filename: automatic_next_path() in shim.c rewrites a -shim[arch].efi suffix to .efi. That is why upstream ships ipxe-shim.efi and snponly-shim.efi as two symlinks to a single shimx64.efi.

Two details that matter in practice:

• The match is -shim plus up to four more characters before .efi, so both snponly-shim.efi and snponly-shimx64.efi work. Either name is fine.
• It is called only from netboot.c and httpboot.c. There is no local-filesystem path, so a shim booted from a USB stick or ESP ignores the rename entirely and goes to its compiled-in default, which for this build is ipxe.efi. Relevant to Chain make_usb.yml to release workflows so the USB image actually gets built fos#129 (make_usb.yml): a Secure Boot USB built this way would silently get the all-drivers binary and hang where this VM did.

Issue checklist

Point	Status
1. Where autoexec.ipxe is fetched from	Answered (previous comment). Re-confirmed here via the shim: fetched from secureboot/, the directory both binaries came from
2. Subdirectory vs TFTP root	Answered. A self-contained /tftpboot/secureboot/ with shim + snponly.efi + autoexec.ipxe works
3. MOK enrolment via mmx64.efi from a PXE-booted shim	Not tested
4. HTTPS expected to fail cleanly	Not tested
5. CONFIG_EFI_STUB=y on the FOS kernel	Not tested — this run stops at the menu

Still unproven

This is a VM, not real hardware, so this does not close the issue. What is proven is the iPXE half: firmware → signed shim → signed iPXE → FOG's boot logic → FOG menu, with Secure Boot enforcing throughout. What remains is everything past the menu — a MOK-signed bzImage actually booting, and a real deploy — which is what #961 and FOGProject/fos#130 are building the signing side for.

Unrelated finding: /tftpboot is mislabelled for SELinux

Surfaced by the audit log during this boot:

avc: denied { read } for comm="in.tftpd" name="default.ipxe"
  scontext=system_u:system_r:tftpd_t:s0
  tcontext=unconfined_u:object_r:default_t:s0 permissive=1

91 of 96 files under /tftpboot carry default_t instead of tftpdir_t (the 5 exceptions are the ones I staged by hand and ran restorecon on). This boot only completed because permissive=1.

The installer never labels these files — checkSELinux() in lib/common/functions.sh offers to set SELinux permissive and does nothing else, and if the admin answers "no" it proceeds anyway. On an enforcing host every PXE boot then fails, and the client reports a bare "file not found" with nothing on the server to explain it.

Not a Secure Boot problem and I have not changed anything for it — noting it here so it is not lost. Happy to raise it separately.

[mastacontrola]

Deploy completed end to end with Secure Boot enforcing

A full image deploy now runs from firmware to Task Complete with Secure Boot on and a self-signed FOS kernel. Closing this.

The chain, all links verified

firmware (Secure Boot ON, MS certs in db)
  -> secureboot/snponly-shimx64.efi   MS UEFI CA 2011+2023, from ipxe/shim ipxe-16.1
  -> secureboot/snponly.efi           iPXE Secure Boot Automatic Code Signing G1A
  -> secureboot/autoexec.ipxe         FOG's boot logic
  -> default.ipxe -> boot.php         task returned directly, no menu
  -> bzImage                          MOK-signed locally, key enrolled on the client
  -> FOS -> partclone -> disk         Cloned successfully

The part that was genuinely uncertain: who verifies the kernel

MOK is shim's database, not the firmware's. So the open question was whether shim's verification protocol survives the handoff into iPXE — if it does not, bs->LoadImage() falls back to firmware db, and a MOK-signed kernel is refused no matter how correctly it is signed.

It survives. iPXE's LoadImage() consulted MokList and accepted the kernel. Nothing extra was needed — no shim command in the boot script, no ShimRetainProtocol handling in FOG's config. The stock upstream pair just works.

Worth recording alongside it: the signed snponly.efi contains no Linux loader at all — zero hits for bzImage/lkrn, because image/lkrn.c is FILE_SECBOOT ( FORBIDDEN ). So under Secure Boot iPXE must hand the kernel to firmware's loader, which means the FOS kernel needs an EFI stub. Both bzImage and bzImage32 already have one — valid PE/COFF with an EFI stub string — so point 5 needed no change.

Evidence

Current block: 2221393, Total block: 10685572, Complete: 20.79%, 11.00GB/min
...
Cloned successfully.
 * Not expanding (/dev/sda5) fixed size
 * Resetting UUIDs for /dev/sda
 * Task Complete
 * Updating Database.................................Done
 * Rebooting system as task is complete

• Host sb-deploy-test, image win11-fostest (format 5), deployed stamped 2026-08-02 06:47:23
• 42 GB written to a previously empty disk (44,522,536,960 bytes)
• FOS hardware inventory populated (VBOX HARDDISK, 3.82 GiB, board/BIOS strings)

Signing procedure

Followed the guide's Step 1 verbatim: openssl req -new -x509 -newkey rsa:2048 -days 3650 -nodes. Both kernels signed with sbsign, .unsigned originals kept.

Explicitly checked that the certificate does not carry the Module-signing only KeyUsage OID 1.3.6.1.4.1.2312.16.1.2, which shim ≥15.4 ignores when validating a boot image. A plain openssl req adds no KeyUsage, so the documented command is safe here — but it is the reason not to reuse a DKMS/mokutil-generated key, which does carry it.

Two documentation bugs found doing this

1. Step 1 cannot work as written. It says to sign with sbsign --cert .../MOK.der, but sbsign reads certificates with PEM_read_bio_X509 and cannot parse DER. DER is what mokutil/MokManager want; sbsign needs PEM. The guide needs an openssl x509 -inform DER -outform PEM step. (Secure Boot: document the signing automation and the enrolment kit fog-docs#84 is already rewriting this file.)
2. The snponly correction from my previous comment is also in Ajax error in login page (dev-branch - build 6303) #84.

Checklist

Point	Status
1. Where autoexec.ipxe is fetched from	Answered — cwuri-relative, plus the TFTP-root fallback
2. Subdirectory vs TFTP root	Answered — self-contained /tftpboot/secureboot/ works
3. MOK enrolment via mmx64.efi from a PXE-booted shim	Not tested — see below
4. HTTPS expected to fail cleanly	Not tested
5. CONFIG_EFI_STUB=y on the FOS kernel	Answered — already present, no change needed

What is still not proven

Being explicit so the record is not overstated:

• This is a VirtualBox VM, not physical hardware. Closing on the strength of the chain being logically complete and every link independently verified, not because hardware was tested. Reports from real machines are still welcome.
• Point 3. The MOK was enrolled with VBoxManage modifynvram enrollmok, which writes MokList directly, rather than through MokManager. This is less of a gap than it looks: mmx64.efi is signed by iPXE's key, so firmware will not launch it directly, and shim only launches it when MokNew is set — which needs mokutil --import from a booted OS. That is exactly why the guide sends you in with a live USB. A diskless PXE client cannot reach MokManager on its own.
• Point 4. HTTPS under Secure Boot was not exercised. Expected to fail by construction (see Feature Request: Support for External Intermediate CA (e.g., Smallstep step-ca) #794).

Unrelated: /tftpboot SELinux labelling

Repeating from my previous comment since it was found here and is not tracked anywhere: 91 of 96 files under /tftpboot carry default_t rather than tftpdir_t, and checkSELinux() only offers to set SELinux permissive. On an enforcing host in.tftpd is denied read and PXE fails as a bare "file not found". Worth its own issue.

Refs #957, #794, #959, #961, FOGProject/fos#130