Issue #645 has been updated by Sean Rhodes. Status changed from New to Closed Priority changed from High to Low Related links updated
---------------------------------------- Bug #645: PCR 0 extended without a corresponding TCG event-log entry on Meteor Lake / FSP coreboot builds https://ticket.coreboot.org/issues/645#change-2298 * Author: Cédric Bussy * Status: Closed * Priority: Low * Category: coreboot common code * Target version: main * Start date: 2026-05-24 * Related links: https://review.coreboot.org/c/coreboot/+/92833 * Affected hardware: Star Labs StarFighter, Intel Core Ultra 5 125H (Meteor Lake) * Affected OS: openSUSE Tumbleweed, kernel 7.0.x, systemd-boot 260.1 ---------------------------------------- **1. Summary** On a Star Labs StarFighter (Intel Core Ultra 5 125H, Meteor Lake) running Star Labs firmware 26.05 (coreboot 26.03-549-g120be1d4d488), PCR 0 holds a non-zero value at runtime, but the TCG event log exposed by the firmware contains no EV_* measurement targeting PCR 0 — only the EV_NO_ACTION Spec ID header (which, per the TCG spec, does not extend the PCR). All real measurements are recorded against PCR 2. Consequently, systemd-pcrlock (used by openSUSE sdbootutil) reconstructs an expected PCR 0 from the log, obtains the initial/reset value, compares it to 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) on every kernel/bootloader update and whenever a tool re-invokes sdbootutil. Note: direct systemd-cryptenroll sealing (which snapshots current PCR values rather than predicting them) is unaffected and works — so this is specifically a pcrlock / event-log-reconstruction issue, not a cryptenroll one. **2. Evidence** PCR state — tpm2_pcrread sha256:0,4,7,9 <pre> 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 - The only entry with PCRIndex 0 is EventNum 0, EventType EV_NO_ACTION (Spec ID Event03; vendorInfo identifies coreboot — CBT22). 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> - The log-reconstructed pcrs: section lists only sha256 PCR 2 = 0x5bd7…. PCR 0 is absent because the log carries no extending measurement for it. The inconsistency: <pre> Reconstructed-from-log PCR 0 = initial value (no extending events) Actual PCR 0 = 0x3D458CFE... => deterministic mismatch </pre> **3. Open question for maintainers (likely root cause)** coreboot measures its own components into PCR 2 and documents PCR 0 as Unused on non-CHROMEOS builds — consistent with the log above. Yet PCR 0 is extended. On Meteor Lake the silicon init runs through Intel FSP (fspm.bin / fsps.bin, both visible in the PCR 2 measurements). The most plausible explanation is that the FSP (or a pre-coreboot CRTM) extends PCR 0 without 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" documentation? 2. If the extension comes from FSP, can coreboot surface those measurements into the TCG event log so that PCR 0 becomes reconstructible — or should PCR 0 be left genuinely unextended on these builds? This is not asserted as a coreboot-only fix; it may require FSP-side coordination. The report's purpose is to surface a reproducible event-log / PCR-0 inconsistency and determine the correct remediation path. **4. Affected scope** - Confirmed: Star Labs StarFighter (Core Ultra 5 125H, Meteor Lake), Star Labs firmware 26.05 (coreboot 26.03-549-g120be1d4d488), openSUSE Tumbleweed, Secure Boot enabled (user mode). - Potentially: any coreboot/FSP build where PCR 0 is extended outside the TCG event log, combined with an OS that defaults 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 UKI + TPM2 LUKS). 3. TPM2 enrolment / boot-entry regeneration fails with the §1 error. 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) scriptlet failed, exit status 1 </pre> The pcrlock.d and %posttrans errors are downstream of the gated PCR 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 4 dropped to avoid re-enrolment on every bootloader change). Automatic unlock works; the firmware-measurement (PCR 0) link is excluded from the policy. Stated as a mitigation, not a fix. **7. Environment** <pre> Device : Star Labs StarFighter; Intel Core Ultra 5 125H (Meteor Lake, stepping C0, microcode 0x28) Firmware : Star Labs 26.05, built on coreboot 26.03-549-g120be1d4d488 (build 2026-04-30 UTC) Intel ME : disabled OS : openSUSE Tumbleweed, kernel 7.0.x, systemd-boot 260.1 Secure Boot: enabled (user mode, custom keys enrolled) TPM : 2.0, sha256 bank systemd 260.1-2.1 sdbootutil 1+git20260506.25d47bf-1.1 tpm2.0-tools 5.7-2.5 </pre> -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
