Summary
The summary boot.json written to /boot/efi/EFI/LamBoot/reports/boot.json records the entry selected, the kernel path, and timing — but no field describing how the binary was verified.
The cross-distro test record from v0.9.0 includes a richer per-event log with strings like verified_via=shim_mok, verified_via=degraded_trust_sb_direct, verified_via=degraded_trust_sb_off. Those events are only emitted on the SDS-3 native PE path, and only land in a separate structured event log (not the summary boot.json).
Result: tools that consume boot.json cannot tell which trust chain ran without also parsing additional log sources, and on some paths (notably entry_type: linux_legacy) no verified_via is emitted at all.
Proposed change
Add a verified_via field to the summary boot.json schema:
{
...,
"entry_type": "linux_legacy",
"verified_via": "firmware_loadimage_via_shim_db",
...
}Possible string values:
native_pe_shim_mok — SDS-3, kernel signed by MOK certnative_pe_shim_db — SDS-3, kernel signed by cert in firmware dbnative_pe_degraded_trust_sb_off — SDS-3, no SB chain to validate againstnative_pe_degraded_trust_sb_direct — SDS-3, SB-on but kernel not verifiable via shim or dbfirmware_loadimage_via_shim — legacy path, verification delegated to shim+firmwarefirmware_loadimage_sb_off — legacy path, no SB
Why summary, not just structured events
The summary file is what external tools (lamboot-monitor, fleet dashboards, audit pipelines) read first. Forcing them to parse a separate structured event log to find the trust path adds friction for an integration field.
Related
Summary
The summary
boot.jsonwritten to/boot/efi/EFI/LamBoot/reports/boot.jsonrecords the entry selected, the kernel path, and timing — but no field describing how the binary was verified.The cross-distro test record from v0.9.0 includes a richer per-event log with strings like
verified_via=shim_mok,verified_via=degraded_trust_sb_direct,verified_via=degraded_trust_sb_off. Those events are only emitted on the SDS-3 native PE path, and only land in a separate structured event log (not the summaryboot.json).Result: tools that consume
boot.jsoncannot tell which trust chain ran without also parsing additional log sources, and on some paths (notablyentry_type: linux_legacy) noverified_viais emitted at all.Proposed change
Add a
verified_viafield to the summaryboot.jsonschema:{ ..., "entry_type": "linux_legacy", "verified_via": "firmware_loadimage_via_shim_db", ... }Possible string values:
native_pe_shim_mok— SDS-3, kernel signed by MOK certnative_pe_shim_db— SDS-3, kernel signed by cert in firmware dbnative_pe_degraded_trust_sb_off— SDS-3, no SB chain to validate againstnative_pe_degraded_trust_sb_direct— SDS-3, SB-on but kernel not verifiable via shim or dbfirmware_loadimage_via_shim— legacy path, verification delegated to shim+firmwarefirmware_loadimage_sb_off— legacy path, no SBWhy summary, not just structured events
The summary file is what external tools (lamboot-monitor, fleet dashboards, audit pipelines) read first. Forcing them to parse a separate structured event log to find the trust path adds friction for an integration field.
Related
legacy_loadimage_usedevent, which captures the same information at the event level. This issue is about the summary representation.entry_type: linux_legacyon Debian 13 + ext2 with noverified_viafield.