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. It’s also the foundation for Path G — a custom PE loader that closes some of these 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. Truncated per boot in v0.8.3; append-mode with crypto signatures in v0.9.x (Path G).

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 deployment postures

Config 1 — SB off. Development / homelab. Everything works, nothing is verified. Trust log records sb_disabled.

Config 2 — firmware DB. Enterprise / internal CA. No shim needed. Simplest production deployment.

Config 3 — shim + MOK. Standard Linux desktop. Runs behind distro shim; users enroll via MokManager.

Config 4 — Zero-touch Proxmox. Custom OVMF_VARS with LamBoot’s db cert pre-enrolled. VM templates at fleet scale.

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