Secure Boot & the Boot Chain
Secure Boot in kldload is fully supported and easy to enable. The recommended path is Bring Your Own Key — supply your existing MOK / fleet signing key and kldload uses it verbatim. Auto-generated keys are also supported for quick starts. The Secure Boot Configuration Reference has the copy-paste steps for every path.
Secure Boot is a UEFI firmware feature that cryptographically verifies each stage of the boot
process before handing control to the next. Firmware verifies the bootloader, the bootloader
verifies the kernel, the kernel verifies its modules. Each signature is checked against a set
of trusted certificates stored in firmware (db) and in shim's Machine Owner Key
(MOK) list.
kldload supports the full chain end-to-end: shim → distro-signed grub → vendor-signed kernel via the existing UEFI CA / vendor-cert trust path that every major distro uses, plus MOK generation (or BYOK) for DKMS module signing — ZFS, WireGuard, and NVIDIA. The only thing kldload signs itself is the kernel-module layer; the boot binaries are already trusted by shim's embedded vendor certs. This page walks through how the chain fits together and how to turn it on. The Configuration Reference has the copy-paste commands.
The boot chain
Every system boots through a chain of stages. Each stage loads the next. Secure Boot means each stage cryptographically verifies the next before handing off control. If any link is unsigned or tampered with, the chain breaks and the system refuses to boot.
shim.efi, which chains to grubx64.efi shipped pre-signed
by the distro (CentOS, Rocky, Fedora, RHEL). Shim's embedded vendor cert already trusts that
signature — no MOK enrollment needed for the boot binaries themselves. ZFSBootMenu still
ships at /EFI/zbm/BOOTX64.EFI, MOK-signed when sbsign is available, as an optional
alternative boot-environment-selection path.KLDLOAD_ENABLE_SECURE_BOOT=1, kldload generates a MOK
keypair during install (or uses your key via KLDLOAD_MOK_KEY_FILE), then
signs every DKMS module through the DKMS sign helper. The kernel verifies the signature
before loading each module under lockdown. A tampered or replaced module fails verification
and the kernel refuses it.KLDLOAD_MOK_KEY_FILE + KLDLOAD_MOK_CERT_FILE to point at a shared organisation key; kldload uses it verbatim and doesn't generate anything new. Either model is supported, neither is mandatory.How to enable it in kldload
kldload deliberately stays out of your security policy. Its job is to lay down the OS with ZFS on root and the value-added kernel modules (ZFS, WireGuard, NVIDIA where applicable) and then hand the box over to you. It does not want to be your PKI, your boot-chain trust root, or your long-term key-management story. Those are yours to own.
So Secure Boot in kldload is opt-in, and the recommended way to turn it on is to bring your own signing key. Your boot chain's trust anchor should be part of your PKI, your lifecycle policy, your rotation schedule — not a random key an installer generated once and left on disk. That's the principle. Everything below is the practical version.
We support three paths, in the order you'll most likely want to use them:
Recommended — Bring Your Own Key (BYOK)
Use your own MOK — an org-issued
cert, an existing machine-owner key, an HSM-backed signing key. Point kldload at it with
KLDLOAD_MOK_KEY_FILE and
KLDLOAD_MOK_CERT_FILE. kldload signs the
chain with your key; if the cert is already enrolled on the firmware, boot under SB
works directly with no MokManager prompt.
Automation — Pre-staged key
For CI/CD and image-build pipelines
that pull signing material from a vault at provisioning time: drop your
mok.key and
mok.pub into
/target/var/lib/dkms/ before the installer's
build phase runs. kldload detects them and uses them verbatim. No env vars, no secrets on the
installer command line.
Quick start — Auto-generated MOK
If you don't have a signing key yet
and want to evaluate SB support without setting up PKI first, set
KLDLOAD_ENABLE_SECURE_BOOT=1 alone. kldload
generates a fresh RSA-2048 keypair, signs everything, and queues MokManager enrollment. Works out
of the box — but the private key lives next to the thing it signs, so it's a quick-start model,
not a production posture.
Recommended path in five commands — your own signing key
# 1. One-time: generate your organisation's MOK (keep .key in your secret store)
openssl req -new -x509 -newkey rsa:2048 -days 3650 -nodes \
-keyout my-mok.key -out my-mok.pub \
-subj "/CN=acme-corp MOK 2026/"
openssl x509 -in my-mok.pub -out my-mok.der -outform DER
# 2. Per box: enroll the public cert once (or pre-enroll via OEM firmware tooling
# if your hardware vendor supports it — skips MokManager entirely)
sudo mokutil --import my-mok.der
# 3. Every kldload install: point at the shared key
export KLDLOAD_ENABLE_SECURE_BOOT=1
export KLDLOAD_MOK_KEY_FILE=/secrets/my-mok.key
export KLDLOAD_MOK_CERT_FILE=/secrets/my-mok.pub
sudo kldload-install-target
# 4. Reboot, approve via MokManager if cert wasn't pre-enrolled
# 5. Turn Secure Boot ON in BIOS, reboot — chain is verified end-to-endOnce the cert is enrolled on a given box, every future kldload install on that box (or any other box with the same cert enrolled) boots under SB directly. No stale MOK accumulation from reinstalls because every build signs with the same key. You own the rotation, the revocation, and the HSM integration — kldload just uses what you give it.
Don't flip Secure Boot on in BIOS until your MOK is enrolled.
Without the MOK enrolled, the boot chain itself still verifies (shim → distro grub → vendor-signed kernel
all ride the vendor cert path), but the kernel will refuse to load zfs.ko
under Secure Boot lockdown — which on a ZFS-on-root system means no rpool import
and a drop into emergency shell. The MokManager flow exists specifically to avoid this — let it run.
Full verification commands, auto-generated-MOK quick-start recipe, retrofit paths for boxes installed without SB, and how to cleanly remove MOK artifacts before reinstalling with a different key are in the Secure Boot Configuration Reference.