Confirm which Secure Boot variables each db enrolment route actually needs (community testing wanted)

[darksidemilk]

FOG's docs now describe two ways to get this server's certificate into UEFI db, and they need different numbers of variables. Only one of them has been tested, and only on a narrow set of machines. This issue is to find out where the line actually falls, with help from the community.

What we think is true

db is what firmware consults to verify a boot image. PK and KEK only control who may change db. So how many variables you need is not a property of db — it is a property of who performs the write, and whether the platform is in Setup/Custom Mode.

Enrolling via	Expected to need	Reasoning
The firmware's own tool, platform in Setup/Custom Mode	db alone	The write is unauthenticated; nothing has to vouch for it
A hypervisor setting (e.g. VMware uefi.secureBoot.dbDefault.file0)	db alone	Same — the hypervisor writes the default before the guest owns the platform
A running OS: FOG's enrolment task, efi-updatevar/similar on Linux, PowerShell's Secure Boot cmdlets	PK, KEK and db	In User Mode a db write must be authenticated by a KEK-signed update, and the machine only trusts FOG's KEK if FOG's PK is enrolled too

What has actually been tested

One cell. On VMware, MOK.der added to db alone — no PK, no KEK — then a FOG-signed EFI binary booted directly with no shim. That is the top row, on one hypervisor.

Everything else in that table is mechanism-based reasoning, not measurement. It is the kind of reasoning that has already been wrong more than once during this work: an earlier round concluded that upstream's iPXE loader "cannot drive virtio" when the actual cause was a firmware NIC with no IPv4 configuration, and a claim that shim derives its second stage purely from its own filename turned out to be incomplete (ipxe/ipxe#1684).

What would help

If you have enrolled FOG's certificate into db, please report:

1. How you enrolled — firmware menu, hypervisor setting, FOG's Enroll Secure Boot Key task, a Linux tool, PowerShell, something else
2. Which variables you wrote — db only, or PK + KEK + db
3. Whether the platform was in Setup/Custom Mode at the time (firmware menus usually label this Custom, not Setup Mode)
4. Whether it worked, and if it failed, what the firmware or tool said
5. Make and model, or hypervisor and firmware build

Specifically useful, because they are the untested cells:

• db alone from a firmware menu on physical hardware — confirmed on VMware only so far
• db alone attempted from an OS tool. If this succeeds anywhere, the User Mode reasoning above is wrong and the docs should say so
• PK + KEK + db from a firmware menu — does any firmware refuse a partial set even in Setup/Custom Mode?
• PowerShell Set-SecureBootUEFI — nobody here has tried it, and it is the route a Windows-shop admin will reach for first
• Anything that triggered BitLocker recovery. Changing Secure Boot variables is measured into PCR 7, so it can; we would like to know how often it does in practice

Why it matters

If the OS-side row is right, then FOG's own enrolment task genuinely needs all three variables and the .auth files are not redundant — which is worth stating clearly, because the db-alone finding makes them look redundant at a glance. If it is wrong, FOG's task could be simplified to a single variable and the enrolment story gets substantially shorter.

Either way the docs currently lean on one measurement, and should not.

Related

• FOGProject/fog-docs#129 — where this is documented; the table above is the corrected version
• #1265 — the local ESP boot archive that made db enrolment worth documenting
• #1266 — two reporting bugs in the enrolment path, which made db enrolment look unavailable on a server that was configured for it

🤖 Generated with Claude Code

https://claude.ai/code/session_017KitrjXwpVEsH4PnKDi83L