Firmware Signing & Secure Boot

How firmware code signing, the UEFI Secure Boot chain of trust, and kernel module signing fit into a CI pipeline that never exposes the private signing key.

Overview

Firmware Signing and Secure Boot

Secure boot exists to answer one question at every stage of startup: is the next piece of code allowed to run here? The answer comes from asymmetric cryptography. A private signing key produces a signature over an artifact; the matching public verification key, baked into read-only silicon or firmware, checks that signature before execution. The private key signs, the public key verifies, and the two are never interchangeable.

Why This Matters for a GPU CI Role

An AMD GPU stack ships firmware for the GPU, its microcontrollers, and sometimes a signed kernel driver. Every one of those artifacts must be signed before it is promoted to a release channel, and the signing has to happen inside CI without ever writing the private key to a build runner. Runners are ephemeral, shared, and frequently compromised, so the key lives in an HSM or a cloud KMS and the pipeline requests signatures over an authenticated channel rather than holding key material.

The Chain of Trust

Trust is anchored in something immutable, typically a public key hash burned into one-time-programmable (OTP) fuses or mask ROM. That root verifies the first-stage bootloader, which verifies the next stage, and so on up to the kernel and its modules. Each link only runs code it can cryptographically verify, so a single unbroken chain from silicon to userspace is what secure boot actually guarantees.

Key concepts

Asymmetric code signing: A signing scheme where a secret private key produces a signature over a digest of the artifact and a freely distributable public key verifies it. Only the private key can sign; possession of the public key never lets an attacker forge signatures. Tools like openssl, sbsign, and pesign implement this over RSA or ECDSA.
Detached signature: A signature stored as a separate file rather than embedded in the artifact, produced with commands like openssl dgst -sign or gpg --detach-sign. Detached signing lets a signing service return only the small signature while the large firmware blob stays on the CI runner, which is central to keeping the private key remote.
Certificate chain and root of trust: A hierarchy where a leaf signing certificate is signed by an intermediate CA, which chains up to a root whose public key (or its hash) is stored immutably in OTP fuses or mask ROM. Verification walks the chain from the artifact's signature up to that immutable anchor; if any link fails, execution is refused.
Anti-rollback version counter: A monotonic counter, held in fuses or a TPM NV index, that records the minimum acceptable firmware version. Boot firmware refuses any image whose embedded version is below the counter, so an attacker cannot downgrade to an older, validly signed but vulnerable image. The counter only ever increases and is bumped after a security fix.
UEFI Secure Boot key hierarchy: Four key databases in firmware: PK (Platform Key) owns the platform and authorizes changes to KEK; KEK (Key Exchange Key) authorizes updates to db and dbx; db holds keys and hashes allowed to boot; dbx is the forbidden list of revoked keys and hashes. A bootloader runs only if it matches db and does not match dbx.
Kernel module signing: With CONFIG_MODULE_SIG and CONFIG_MODULE_SIG_FORCE, the kernel appends a signature to each .ko using scripts/sign-file and verifies it against keys in the kernel keyring at load time. On a Secure Boot host with lockdown, an unsigned or wrongly signed module is rejected, so out-of-tree drivers must be signed by an enrolled key.
Measured boot versus secure boot: Secure boot enforces a policy: it halts if code fails verification. Measured boot enforces nothing at boot time; each stage hashes the next and extends the digest into a TPM PCR, producing an attestable record. Secure boot answers is this allowed to run, measured boot answers what actually ran, and the two are complementary.

When to use it

You must add a signing step to a CI pipeline for firmware, a bootloader, or a kernel driver and cannot allow the private key to touch a build runner.
You are debugging why a signed kernel module refuses to load, or a bootloader is rejected, on a host with UEFI Secure Boot enabled.
A signing key or certificate is suspected compromised and you need to rotate it and revoke every artifact it signed via dbx or a CRL.
You are adding a release gate that must independently verify an artifact's signature before it is promoted to a production channel.
You are designing an offline or isolated signing service that a pipeline calls over the network to obtain signatures without ever exposing key material.

Interview questions

How do you integrate firmware signing into a CI pipeline without ever exposing the private key on a runner?
Explain the secure-boot chain of trust and how you would validate it end to end.
How do you sign a kernel module so it loads on a host with UEFI Secure Boot enabled?
A signing key is suspected compromised. How do you rotate and revoke it?
How do you make signature verification a hard CI gate before promotion?
Design an offline signing enclave that a pipeline requests signatures from.