Fixed the secure boot enrollment script

This commit is contained in:
Audiobuzz
2026-06-20 12:16:37 +00:00
parent 33583bb4d8
commit d2b2156a22
7 changed files with 194 additions and 45 deletions
+28 -2
View File
@@ -622,10 +622,29 @@ smoke test.
Removes `rd.dot1x=0`/`ip=dhcp`; the hook owns the link (macsec0).
- **NVMe discovery by DNS:** `nvmet_traddr=nvme.fleet.lab` (CI), resolved at boot
by the serving dnsmasq — drop the hardcoded `192.168.50.10`.
- **Signing:** wire `sb_key`/`sb_cert` (CI/HSM secrets) for a signed UKI; enable
Secure Boot on targets. Until then the loud unsigned warning must stay.
- **Signing — SIGNED-UKI + SECURE-BOOT-ON PATH BENCH-VERIFIED on the Proxmox VM
(HTTP boot, 2026-06-20).** CI signs the UKI when `SB_KEY`/`SB_CERT` secrets are
set (`db` key); `fleet-sb-enroll` enrols db→KEK→PK from the baked public `.auth`
files; OVMF then boots the signed UKI under enforcing Secure Boot. Confirmed
end-to-end: CI-signed UKI verifies (`sbverify`), enrolment succeeds, VM boots
with `mokutil --sb-state` = enabled.
**Key generation + enrolment procedure: [secure-boot-keys.md](secure-boot-keys.md)**
(the PK/KEK/db trio; `db` = `sb_key`/`sb_cert`, PK/KEK stay offline).
- **Bug fixed during bring-up (2026-06-20):** `fleet-sb-enroll` built its 4-byte
EFI attribute prefix in a bash variable (`ATTR=$'\x27\x00\x00\x00'`). Bash
strings can't hold NULs → only `0x27` survived → efivarfs read a corrupt
attribute u32 → every write failed with `EINVAL` ("dd: Invalid argument").
Now emitted directly with `printf` at write time. (Red herring on the way:
Proxmox EFI disks default to `pre-enrolled-keys=1`, so `mokutil --db` shows
the MS cert even in Setup Mode — looked like a non-empty-db rejection but was
the NUL bug all along; it failed identically on a clean `pre-enrolled-keys=0`
disk.)
- **REMAINING for production:** (a) **secure path** — re-verify signed boot with
`disable_dot1x=false` (802.1X/MACsec), not just the test path; (b) **820 / PXE
path** — sign `snponly.efi` with the same `db` key so the iPXE front-end also
passes Secure Boot (the VM's HTTP path has no iPXE stage, so this is still
unverified on real PXE hardware); (c) confirm signing is reproducible (verity
hash stable across two signed builds).
- **PXE-only iPXE fallback — BENCH-VERIFIED on the EliteBook 820 G4 (2026-06-20).**
Firmware without UEFI HTTP boot chainloads `serving/tftp/snponly.efi` → renders
`autoexec.ipxe` (ifopen + DHCP-retry + `imgargs <real cmdline>`) → UKI over HTTP
@@ -638,6 +657,13 @@ smoke test.
(iii) iPXE aborts the script on any unguarded command failure (use `||`);
(iv) Secure Boot OFF makes systemd-stub take iPXE's load options as the cmdline,
so the entrypoint extracts the UKI's real `.cmdline` and feeds it via `imgargs`.
**Tidied 2026-06-20** once PortFast was identified: dropped the `autoexec.ipxe` +
`ifopen` + DHCP-retry STP workaround; `boot.ipxe` is now just
`dhcp`+`imgfetch`+`imgargs`+`boot` reached via normal iPXE autoboot. Re-verified
on the 820 G4. **SB-on simplification:** when Secure Boot is enabled the cmdline
injection is unnecessary (the stub ignores the loader cmdline) — collapse
`boot.ipxe` to a plain `chain` of the UKI and drop the `.cmdline` extraction +
`binutils` + the artifact mount from the dnsmasq service.
- **Sign iPXE for the PXE-only fallback (Secure Boot, production).** The lab
`snponly.efi` is **UNSIGNED** → that path needs **Secure Boot OFF**. For
production: `sbsign` the iPXE binary with the fleet **db** key (only `db` needed —