Bug #645
Updated by Cédric Bussy 2 days ago
**1. Summary** On a Star Labs StarFighter (Intel Core Ultra 5 125H, Meteor Lake) running Star running Star Labs firmware 26.05 (coreboot 26.03-549-g120be1d4d488), PCR 0 holds a non-zero a non-zero value at runtime, but the TCG event TCG event log exposed by the firmware contains no EV_* measurement targeting PCR targeting PCR 0 — only the EV_NO_ACTION Spec ID header (which, per the TCG spec, does not does not extend the PCR). All real measurements are recorded against PCR 2. Consequently, systemd-pcrlock (used by openSUSE sdbootutil) reconstructs an expected an expected PCR 0 from the log, obtains the initial/reset value, compares it to the actual the actual register, and fails: <pre> Event log for PCR 0 does not match PCR state, refusing. </pre> This blocks TPM2 measured-boot operations (boot-entry regeneration, pcrlock prediction) pcrlock prediction) on every kernel/bootloader update and whenever a tool re-invokes sdbootutil. re-invokes sdbootutil. Note: direct systemd-cryptenroll sealing (which snapshots current PCR current PCR values rather than predicting them) is unaffected and works — so this is specifically is specifically a pcrlock / event-log-reconstruction pcrlock/event-log-reconstruction issue, not a cryptenroll one. **2. Evidence** PCR state — tpm2_pcrread sha256:0,4,7,9 <pre> (tpm2_pcrread sha256:0,4,7,9) 0 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969 4 : 0xAED40B050E1BA97F3AE98794456DDD937ACD41EC0D7602580A088683DD32457C 7 : 0x2C71FF90E89217C2B534F24FE456BC6FDE79E90517634D6CED60B4D7AE0A2267 9 : 0xEEC49DD0A2BD6FCAECF0FD28D3E15382E94A34956D37DB7501FC081359D8B645 </pre> PCR 0 is non-zero — it has been extended during this boot. Event log — tpm2_eventlog .../binary_bios_measurements - (tpm2_eventlog .../binary_bios_measurements) • The only entry with PCRIndex PCRIndex: 0 is EventNum 0, EventType EV_NO_ACTION (Spec EventType: EV_NO_ACTION (Spec ID Event03; vendorInfo identifies coreboot — CBT22). EV_NO_ACTION does EV_NO_ACTION does not extend the PCR. - • Every measurement event (EventNum 1–12, EV_ACTION) targets PCR 2: <pre> CBFS: bootblock CBFS: fallback/romstage CBFS: fspm.bin CBFS: spd.bin CBFS: fallback/postcar CBFS: fallback/ramstage CBFS: cpu_microcode_blob.bin CBFS: fsps.bin CBFS: vbt_qhd.bin CBFS: fallback/dsdt.aml CBFS: fallback/payload </pre> - 2: CBFS: bootblock, fallback/romstage, fspm.bin, spd.bin, fallback/postcar, fallback/ramstage, cpu_microcode_blob.bin, fsps.bin, vbt_qhd.bin, fallback/dsdt.aml, fallback/payload. • The log-reconstructed pcrs: section lists only sha256 PCR sha256: 2 = 0x5bd7…. PCR : 0x5bd7…. PCR 0 is absent because the log carries no extending measurement for it. The inconsistency: <pre> inconsistency • Reconstructed-from-log PCR 0 = initial value (no extending events) events). • Actual PCR 0 = 0x3D458CFE... => 0x3D458CFE…. • → deterministic mismatch </pre> mismatch. **3. Open question for maintainers (likely root cause)** coreboot measures its own components into PCR 2 and documents PCR 0 as Unused on Unused on non-CHROMEOS builds — consistent with the log above. Yet PCR 0 is extended. On extended. On Meteor Lake the silicon init runs through Intel FSP (fspm.bin / fsps.bin, / fsps.bin, both visible in the PCR 2 measurements). The most plausible explanation plausible explanation is that the FSP (or a pre-coreboot CRTM) extends PCR 0 without the measurement the measurement being reflected in coreboot's TCG event log. Questions: 1. Is PCR 0 expected to be extended on Meteor Lake FSP-based builds despite the "Unused" the "Unused" documentation? 2. If the extension comes from FSP, can coreboot surface those measurements into the into the TCG event log so that PCR 0 becomes reconstructible — or should PCR 0 be left be left genuinely unextended on these builds? This is not asserted as a coreboot-only fix; it may require FSP-side coordination. FSP-side coordination. The report's purpose is to surface a reproducible event-log / PCR-0 / PCR-0 inconsistency and determine the correct remediation path. **4. Affected scope** - • Confirmed: Star Labs StarFighter (Core Ultra 5 125H, Meteor Lake), Star Labs Lake), coreboot firmware 26.05 (coreboot 26.03-549-g120be1d4d488), 26.05, openSUSE Tumbleweed, Secure Boot enabled (user mode). - • Potentially: any coreboot/FSP build where PCR 0 is extended outside the TCG the TCG event log, combined with an OS that defaults to sdbootutil to sdbootutil / systemd-pcrlock / measured UKI for TPM2 LUKS. **5. Reproduction** 1. coreboot/FSP build, non-CHROMEOS, TPM2 active, Secure Boot user mode. 2. Install openSUSE Tumbleweed (defaults to sdbootutil / systemd-pcrlock for measured for measured UKI + TPM2 LUKS). 3. TPM2 enrolment / boot-entry regeneration fails with the §1 error. Correlated install-time Correlated install-time symptoms: <pre> Event log for PCR 0 does not match PCR state, refusing. find: '/var/lib/pcrlock.d/': No such file or directory warning: %posttrans(coreutils-X.Y.Z.x86_64) %posttrans(coreutils-<ver>.x86_64) scriptlet failed, exit status 1 </pre> The pcrlock.d and %posttrans errors are downstream of the gated PCR 0 validation, 0 validation, not independent faults. **6. Current mitigation (reporter's system)** <pre> measure-pcr-validator.ignore=yes # /etc/kernel/cmdline </pre> LUKS sealing then performed via systemd-cryptenroll against PCR 7+9 (PCR 7+9 (PCR 4 dropped to avoid re-enrolment on every bootloader change). Automatic unlock Automatic unlock works; the firmware-measurement (PCR 0) link is excluded from the policy. Stated policy. Stated as a mitigation, not a fix. **7. Environment** <pre> Device : • Device: Star Labs StarFighter; Intel Core Ultra 5 125H (Meteor Lake, stepping C0, microcode 0x28) Firmware : • Firmware: Star Labs 26.05, built on coreboot 26.03-549-g120be1d4d488 (build 2026-04-30 UTC) • Intel ME : ME: disabled OS : • OS: openSUSE Tumbleweed, kernel 7.0.x, systemd-boot 260.1 • Secure Boot: enabled (user mode, custom keys enrolled) TPM : • TPM: 2.0, sha256 bank • systemd 260.1-2.1 • sdbootutil 1+git20260506.25d47bf-1.1 • tpm2.0-tools 5.7-2.5 </pre>