scroll-secure

UEFI Secure Boot · PK / KEK / db

Your own Secure Boot keys. Without the black screen.

Replace the vendor keys and drop the Microsoft CA, and the firmware stops trusting the GPU's option ROM. On a machine with no integrated graphics, that means no display before the OS boots, including firmware setup. scroll-secure allowlists exactly your card's firmware driver, by hash.

Why the screen goes black

A discrete GPU carries its own UEFI driver, the GOP, in an option ROM. Vendors sign it with Microsoft's third-party UEFI CA. Once your db holds only your certificate, the firmware refuses to load that driver.

The usual advice is "keep the Microsoft keys", but then anything Microsoft ever signed can boot on your machine. The precise fix is to add the SHA-256 hash of that one driver to db.

Where the hash comes from

The firmware already measures every option ROM driver it loads into the TPM: PCR 2, event type EV_EFI_BOOT_SERVICES_DRIVER. The event log records its Authenticode SHA-256, the exact value db expects. Nothing is guessed and no ROM gets dumped. The same idea as sbctl enroll-keys --tpm-eventlog, in a self-contained bash script.

One script: create, enroll, status

# on a trusted machine, keys onto offline media
SECRETS_DIR=/media/keys image/uki/secure-boot-keys.sh create

# on the installed system, firmware in Setup Mode
run0 /usr/libexec/scroll-secure/secure-boot-keys enroll --dry-run
run0 /usr/libexec/scroll-secure/secure-boot-keys enroll
run0 /usr/libexec/scroll-secure/secure-boot-keys status

enroll fails closed. It refuses to write anything if:

  • the firmware isn't in Setup Mode
  • any .efi on the ESP isn't signed by the db certificate you're enrolling, which would mean an unbootable machine
  • the TPM event log can't be read or parsed. Silently dropping the ROM hashes is how black screens happen.

Before writing, it backs up the current PK, KEK, db and dbx. It writes db, then KEK, then PK last, which leaves Setup Mode. Then it reads every variable back and checks that your certificates and every ROM hash actually landed.

Tested end to end in KVM: OVMF starts in Setup Mode with a NIC whose option ROM is measured. The script enrolls, and the next boot runs with Secure Boot enforced on a chain signed with your keys and the ROM hash in db. On real hardware, keep the CMOS-clear route to factory keys in mind as your way back.

What else your keys sign

  • systemd-boot and the unified kernel image (kernel + initramfs + command line), on every build
  • The PCR 11 policy, with a separate PCR key, so the TPM unlocks only kernels you built. How the disk unlock uses it →
  • The container image, with cosign. The installer pulls nothing it can't verify.

Private keys never enter a build layer. They're mounted as podman build secrets for the signing steps only, from media you keep offline.