Skip to content

fog.enrollsb: confirm the PK by reading it back, not by SetupMode - #202

Merged
mastacontrola merged 1 commit into
masterfrom
fix/sb-enroll-pk-readback
Nov 5, 2026
Merged

mastacontrola merged 1 commit into
masterfrom
fix/sb-enroll-pk-readback

Conversation

@mastacontrola

Copy link
Copy Markdown
Member

Problem

Forum topic 18307. The unattended "Enroll Secure Boot Key" task printed:

Automatic Secure Boot enrollment failed. This machine is still in Setup Mode …

The machine came back in Custom Mode. A second run found the certificate already in db. So db, KEK and PK all landed, and the message was false.

Cause

sbEnrollDb() confirmed the PK write by requiring SetupMode to read 0 immediately after it. Some firmware stores the PK and keeps reporting SetupMode=1 until the next reset.

Change

  • sbPkReadback() reads PK back through efivarfs (GetVariable) and compares it to the EFI_SIGNATURE_LIST inside PK.auth, at 16 + dwLength. It returns 0 (FOG's PK), 1 (absent: still Setup Mode), or 2 (some other PK).
  • sbEnrollDb() runs the readback even when the PK dd reports an error. A db or KEK failure still stops before the PK write.
  • sbEnroll() gives each outcome its own message. rc 2 no longer claims Setup Mode. On success it prints a note when SetupMode still reads 1.
  • ADR 0009 and the fog.enrollsbforce comment describe the new check.

Tests

  • The dd test double now stores what firmware keeps: the attribute word plus the signature list, not the auth descriptor.
  • Case 39 changed from "SetupMode stays 1 → refuse" to "PK stored, SetupMode stale → success". Cases 39a–39g cover a declined PK, a failed PK write, a stored PK with a dd error, a foreign PK, and each message.
  • 40b/40c use a real PK.auth made by efitools sign-efi-sig-list (throwaway key, not committed) and its PK.esl, so the dwLength parse is not checked against its own assumption.
  • tests/checks/secureboot.sh: 95 passed, 0 failed. Restoring the old SetupMode gate turns 39/39a red. A wrong payload offset turns 40b/40c red.

Verified

On QEMU/OVMF (q35, SMM, Secure Boot firmware) in Setup Mode, with FOG's published PK/KEK/db.auth, the patched sbEnrollDb returned 0. The PK read back is byte-identical to the PK.auth payload (1407 bytes). A foreign payload returns 2.

Not verified: vendor firmware that reports a stale SetupMode. OVMF flips it at once.

🤖 Generated with Claude Code

Forum topic 18307: the unattended Secure Boot enrollment said "Automatic
Secure Boot enrollment failed ... still in Setup Mode". The machine came
back in Custom Mode, and a second run found the certificate in db. So
db, KEK and PK all landed. The failure came from the check after the PK
write: SetupMode still read 1. Some firmware updates that flag only at
the next reset.

sbEnrollDb now reads PK back through efivarfs and compares it to the
EFI_SIGNATURE_LIST inside PK.auth. It runs that check even when dd
reports an error. A db or KEK failure still stops before PK.

The result has three outcomes:
- PK is FOG's: success. A note prints if SetupMode still reads 1.
- PK is absent: the existing "still in Setup Mode" message, now true.
- PK is something else: a new message that does not claim Setup Mode.

The dd test double now stores what firmware keeps (attribute word plus
signature list), and a real PK.auth from efitools gates the dwLength
parse. Verified on QEMU/OVMF with FOG's published PK/KEK/db.auth: the
PK reads back byte-identical to the PK.auth payload.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@mastacontrola
mastacontrola merged commit 7fcab85 into master Nov 5, 2026
1 check passed
@mastacontrola
mastacontrola deleted the fix/sb-enroll-pk-readback branch November 5, 2026 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant