kldload — Secure Boot: Why the Boot Chain Is the Most Important Attack Surface

Learn

Secure Boot — why the boot chain is the most dangerous attack surface.

Every security tool you run — your firewall, your EDR, your antivirus, your container runtime — loads after the kernel. If an attacker gets code running before the kernel, they own everything that comes after it. Your security tools can't detect what's already beneath them.

The uncomfortable reality: A motivated teenager with YouTube and a Kali Linux VM can download pre-built rootkit frameworks, bootkit toolkits, and UEFI attack tools that do the hard work for them. The knowledge barrier is nearly gone. Tools like BootHole, BlackLotus, and CosmicStrand are publicly documented with working proof-of-concept code.

What a boot-level rootkit can do

It loads before your OS

A rootkit in the UEFI firmware or bootloader loads before the kernel, before your antivirus, before your EDR, before your security tools even exist in memory. It can subvert everything that loads after it — including the kernel itself.

Most detection tools run inside the OS. The rootkit already owns the OS.

It survives reinstalls

UEFI rootkits live in firmware, not on disk. Reinstalling the OS doesn't help. Reformatting doesn't help. Some survive firmware flashes. The only reliable fix is replacing the hardware.

You can't clean a house by repainting the walls when the foundation is compromised.

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.

Stage 1 — UEFI Firmware

The hardware starts here. Secure Boot is a UEFI feature that checks: is the bootloader signed by a trusted key? If not, stop. This is the root of trust — everything downstream depends on this check.

Stage 2 — Bootloader (ZFSBootMenu)

Signed and verified by UEFI. ZFSBootMenu selects which boot environment to load. It must be signed or the firmware won't run it. On kldloadOS, this is the EFI binary installed to the ESP.

Stage 3 — Kernel

Signed by the distro vendor. The bootloader loads the kernel. If Secure Boot is enforcing, only a signed kernel will load. An attacker who modified the kernel binary gets caught here.

Stage 4 — Kernel Modules (DKMS)

Signed per-machine via MOK. ZFS, WireGuard, and NVIDIA are out-of-tree modules built via DKMS. kldloadOS generates a Machine Owner Key during install and signs every module. The kernel verifies the signature before loading each one.

Stage 5 — Userspace

Everything above is verified. By the time systemd starts, every component in the boot chain has been cryptographically checked. A rootkit injected at any stage would have broken the chain and been caught.

Without Secure Boot

Stage 1 — UEFI Firmware

Runs whatever bootloader it finds. No signature check. A rootkit that replaced the bootloader binary gets executed with full trust.

Stage 2 — Bootloader

Unverified. Could be legitimate. Could be malware. The firmware doesn't know and doesn't check.

Stage 3 — Kernel

Unverified. The bootloader loads whatever kernel it's pointed at. A modified kernel with a backdoor loads without resistance.

Stage 4 — Modules

Unsigned. Any kernel module loads. A malicious module has full kernel access — read memory, intercept syscalls, hide processes.

Stage 5 — Userspace

Your security tools start. But they're running on a kernel that might already be compromised. Every security decision they make is based on information provided by a potentially hostile kernel. They cannot detect what they cannot see.

The Kubernetes nightmare

This isn't theoretical. Here's what happens when a rootkit meets a Kubernetes cluster that doesn't verify boot integrity:

The attack chain

The rootkit loads before the OS. It reads the kubelet's TLS client certificate from memory. It presents that cert to the Kubernetes API server. The API server sees a valid cert signed by the cluster CA — the TLS handshake succeeds. The rootkit now has legitimate node-level access to the cluster.

mTLS just means both sides have certs. It says nothing about whether the machine was compromised at boot.

The blast radius

With a stolen kubelet cert: read all secrets across every namespace the node touches. Inject containers into running pods. Exfiltrate the etcd database. Pivot to every node the compromised identity can reach. All over valid TLS. All with valid certs. Completely invisible to standard monitoring.

The cluster has no native way to detect this is happening.

Where kldloadOS stands

✓ UEFI Secure Boot
✓ MOK-signed DKMS modules (ZFS, WireGuard, NVIDIA)
✓ ZFS integrity checking (every block checksummed)
✓ WireGuard encryption at second zero
✓ eBPF observability from kernel load
✗ TPM-2 measured boot (planned)
✗ Remote attestation before cluster admission (planned)
✗ Kubernetes admission webhook verifying boot integrity (planned)

The full solution

The complete chain looks like this:

Secure Boot verifies the bootloader, kernel, and modules. TPM-2 measures every stage and seals secrets against those measurements. Remote attestation (Keylime or similar) lets the cluster ask each node: "prove your boot chain was clean before I accept your credentials." Kubernetes admission control refuses nodes that can't prove clean boot. Cilium network policy limits blast radius even if a node is compromised.

kldloadOS has the first two layers today. The attestation layer is on the roadmap. But even without it — most enterprise Linux deployments ship with Secure Boot disabled, unsigned modules, no TPM attestation, and a boot process a motivated teenager could subvert.

The bar is low. kldloadOS is already above it.

← Kernel vs Userland ↑ Top