Honest Security Story

What LamBoot defends — and what it doesn't. The single biggest differentiator, not softened.

Every Linux bootloader page on every project’s website lies a little bit about security. They say “Secure Boot: yes” and stop. The real picture is uncomfortable:

shim 15.8’s OVERRIDE_SECURITY_POLICY is undefined in upstream Makefile, making the SecurityArch hook dead code
shim’s SBAT enforcement is asymmetric (different behaviour for in-protocol vs. direct loads)
every major Linux bootloader — GRUB, systemd-boot, rEFInd, even shim itself — bypasses Secure Boot for kernel loads via gBS->LoadImage replacement or filesystem driver tricks or out-of-band verification.

LamBoot does not hide this. This page does not either.

WHAT LAMBOOT DEFENDS

What LamBoot does defend against

Threat	Defense
Unsigned `lambootx64.efi` replacement on ESP	Firmware DB / shim / MOK verification refuses to load
Unsigned filesystem driver substitution	SecurityOverride delegates to ShimLock; unsigned drivers are rejected and logged
Unsigned kernel substitution	Same — ShimLock-gated via SecurityOverride when the kernel loads
Policy-file tampering	Measured into PCR 5; remote attestation can detect
Cmdline injection at LamBoot layer	Measured into PCR 12; remote attestation can detect
Silent crash loops masking an attack	State machine surfaces to NVRAM readable by host monitoring
Unauditable trust decisions	Every decision recorded to `\loader\boot-trust.log` on the ESP

INHERITED ECOSYSTEM GAPS

What LamBoot does not defend against

Every bootloader inherits these gaps. LamBoot names them.

Threat	Why not	Mitigation (external)
Kernel binary swap post-verification	LoadFile2 is a protocol handoff; the kernel reads its own initrd/setup-header after LamBoot exits	Measured Boot + IMA inside the kernel; `ima-evm-utils`
Initrd content tampering	Initrd integrity is not covered by Secure Boot in any mainstream Linux distro	Use Unified Kernel Images (UKI) — LamBoot supports them first-class — or `dm-verity` / `systemd-pcrphase`
Firmware-level compromise (SEC / PEI)	Below the Secure Boot trust boundary	Platform manufacturer firmware updates; Intel Boot Guard / AMD PSB
GRUB-style cmdline injection via config file on writable ESP	ESP is typically FAT and writable from the OS	Lock down ESP mount; sign `policy.toml` (roadmap); measure cmdline to PCR 12 (already done)
Runtime SMM attacks	Below the OS trust boundary	SMM hardening is a firmware problem

THE DIFFERENTIATOR

Why this honesty matters

Every other bootloader page treats Secure Boot as a checkbox. This one treats it as a system property with documented gaps and a plan. That’s what the security-conscious users LamBoot targets actually want to read. v0.9.0’s Path G — native ext4 reader, native PE loader, native trust chain — closes the largest of those gaps in-bootloader rather than punting to the kernel.

When someone asks “is LamBoot secure?”, the answer is: it’s more auditable than the alternatives — here’s every decision it made last boot, here’s what it can and cannot protect, here’s the roadmap for closing the remaining gaps. That answer is rare and it’s what buys credibility.

TRUST-EVIDENCE LOG

The audit format

One JSON object per line in \loader\boot-trust.log on the EFI System Partition. Append-mode with per-image SHA-256 in v0.9.0; per-event crypto signing on the v0.9.x polish track.

sample output

{"seq":0,"event":"boot_start","path":"","size":0,"sha256":"","verified_via":"","status":"","note":"secure_boot=true"}
{"seq":1,"event":"driver_loaded","path":"\\EFI\\LamBoot\\drivers\\ext4_x64.efi","size":0,"sha256":"","verified_via":"shim_mok","status":"Success","note":""}
{"seq":2,"event":"boot_attempt","path":"\\EFI\\Linux\\ubuntu-6.11.efi","size":0,"sha256":"","verified_via":"firmware_db","status":"Success","note":"uki"}

Fields

seq — monotonic sequence within boot
event — boot_start | driver_loaded | driver_rejected | boot_attempt
path — EFI path (empty for boot_start)
status — UEFI status name
note — free-form

`verified_via` values

firmware_db — firmware trust DB accepted
shim_mok — shim accepted via MOK cert
shim_vendor — shim accepted via vendor cert
security_override — LamBoot’s hook delegated to shim
rejected — image refused
sb_disabled — Secure Boot not enforced

TPM MEASURED BOOT

PCR measurements

PCR	What
4	Kernel image Authenticode hash
5	`policy.toml` content
12	Kernel command line (UTF-16)

Gracefully degrades when TPM is absent.

SECURE BOOT CONFIGS

Four postures — with honest works-when notes

WORKS TODAYConfig 1 — SB off.

Development / homelab. All features, all filesystems, no caveats. Trust log records sb_disabled.

WORKSConfig 2 — firmware DB.

Enterprise / owned hardware. Works with firmware-DB-signed kernels (self-signed UKI, custom build). Stock distro kernels boot end-to-end via Config 3 (shim + MOK) on ext4 /boot in v0.9.0.

WORKSConfig 3 — shim + MOK.

Stock Ubuntu / Debian / Fedora / Pop!_OS desktop. Works end-to-end on stock distro /boot-on-ext4 in v0.9.0 via the native ext4 reader + native PE loader + native trust chain. The earlier shim 15.8 caveat no longer applies. UKI on ESP also works first-class.

WORKSConfig 4 — Proxmox zero-touch.

Pre-enrolled OVMF_VARS for VM fleets. Works end-to-end on stock distro VM images in v0.9.0 via the native ext4 reader + native PE loader + native trust chain. UKI-based VM images also work.

v0.9.0 delivers native read-only /boot access on ext4 via the ext4-view Rust crate, a native PE loader, and a native trust chain — closing the Config 3 / Config 4 ext4-/boot gap without the kernel-on-ESP duplication that sd-boot requires. See architecture and roadmap.

Read the deeper threat model

The repo’s docs/SECURITY-MODEL.md goes deeper than this page, and the code is audit-friendly.

SECURITY-MODEL.md Install FAQ