ProductsLamBoot › Security

Security and trust

LamBoot records every image-authentication decision it makes, and documents exactly where its verification ends.

Secure Boot is a trust chain, and most tools treat it as a yes-or-no checkbox. LamBoot treats it as something you can audit. It records every image-authentication decision it makes, it documents exactly where its verification ends and other layers take over, and it states plainly what it can and cannot protect.

WHAT IT VERIFIES AND STOPS

What LamBoot verifies and stops

Threat What LamBoot does
Unsigned lambootx64.efi replacement on the ESPFirmware DB, shim, or MOK verification refuses to load it.
Unsigned filesystem driver substitutionSecurityOverride delegates to ShimLock. Unsigned drivers are rejected and logged.
Unsigned kernel substitutionShimLock-gated through SecurityOverride when the kernel loads.
Policy file tamperingMeasured into PCR 5. Remote attestation can detect it.
Command line injection at the LamBoot layerMeasured into PCR 12. Remote attestation can detect it.
Crash loops masking an attackThe NVRAM state machine surfaces the count to the host.
Unauditable trust decisionsEvery decision is recorded to \loader\boot-trust.log.
THE TRUST BOUNDARY

Where the trust chain ends, and what continues it

LamBoot verifies the boot path up to the point it hands control to the kernel. Past that boundary, these layers carry the chain.

Boundary What continues the chain
The kernel reads its own initrd and setup header after LamBoot exitsMeasured Boot and IMA inside the kernel (ima-evm-utils)
Initrd content integrity (not covered by Secure Boot in any mainstream distro)Unified Kernel Images, which LamBoot supports first-class, or dm-verity / systemd-pcrphase
Firmware level (SEC and PEI), below the Secure Boot boundaryPlatform firmware updates, Intel Boot Guard, AMD PSB
Command line via a writable ESPLamBoot measures the cmdline into PCR 12 today. Lock the ESP mount. Signed policy is on the roadmap.
Runtime SMM, below the OS boundaryFirmware hardening
TRUST-EVIDENCE LOG

The trust-evidence log format

One JSON object per line in \loader\boot-trust.log on the EFI System Partition. The SHA-256 of each verified image is populated, and the verify record and the load record carry the same hash.

\loader\boot-trust.log (sample)
{"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":134144,"sha256":"6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b","verified_via":"shim_mok","status":"Success","note":""}
{"seq":2,"event":"boot_attempt","path":"\\EFI\\Linux\\ubuntu-6.11.efi","size":42139648,"sha256":"d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35","verified_via":"firmware_db","status":"Success","note":"uki"}

Fields

  • seq. Monotonic sequence within the boot.
  • event. boot_start, driver_loaded, driver_rejected, boot_attempt, legacy_loadimage_used.
  • path, size, sha256. The image, its size, and its hash.
  • status. The 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.
  • sb_disabled. Secure Boot not enforced.
  • rejected. Image refused.
TPM MEASURED BOOT

PCR measurements

When a TPM is present, LamBoot measures into:

PCR What
4Kernel image Authenticode hash
5policy.toml content
12Kernel command line

It degrades gracefully when no TPM is present.

SECURE BOOT CONFIGS

Four Secure Boot configurations

Config 1, Secure Boot off. Development and homelab. All features, all filesystems, no enrollment. The log records sb_disabled.
Config 2, firmware DB. You own the hardware and enroll LamBoot's key in firmware db. Boots firmware-db-signed kernels (self-signed UKI, custom build).
Config 3, shim plus MOK. Stock Ubuntu, Debian, Fedora, Pop!_OS. Boots stock distro /boot on ext4 end to end through LamBoot's native ext4 reader, native PE loader, and native trust chain. A pre-enroll option (LamBoot's signing cert placed in firmware db ahead of time) makes the first boot non-interactive while shim stays in the chain.
Config 4, Proxmox zero-touch. Pre-enrolled OVMF_VARS for VM fleets. Boots stock distro VM images end to end. An in-place modification path injects LamBoot's signing cert into a VM's existing UEFI state without replacing the template.

Production Secure Boot today means enrolling LamBoot's key once through MOK or firmware db, and the shim-review submission that removes that one-time step is on the roadmap.