Issue #645 has been reported by Cédric Bussy.
----------------------------------------
Bug #645: PCR 0 extended without a corresponding TCG event-log entry on Meteor
Lake / FSP coreboot builds
https://ticket.coreboot.org/issues/645
* Author: Cédric Bussy
* Status: New
* Priority: High
* Category: coreboot common code
* Target version: main
* Start date: 2026-05-24
* 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:
Event log for PCR 0 does not match PCR state, refusing.
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)
0 : 0x3D458CFE55CC03EA1F443F1562BEEC8DF51C75E14A9FCF9A7234A13F198E7969
4 : 0xAED40B050E1BA97F3AE98794456DDD937ACD41EC0D7602580A088683DD32457C
7 : 0x2C71FF90E89217C2B534F24FE456BC6FDE79E90517634D6CED60B4D7AE0A2267
9 : 0xEEC49DD0A2BD6FCAECF0FD28D3E15382E94A34956D37DB7501FC081359D8B645
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: 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: 2 : 0x5bd7…. PCR 0
is absent because the log carries no extending measurement for it.
The inconsistency
• Reconstructed-from-log PCR 0 = initial value (no extending events).
• Actual PCR 0 = 0x3D458CFE….
• → deterministic mismatch.
**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),
coreboot firmware 26.05, 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:
Event log for PCR 0 does not match PCR state, refusing.
find: '/var/lib/pcrlock.d/': No such file or directory
warning: %posttrans(coreutils-<ver>.x86_64) scriptlet failed, exit status 1
The pcrlock.d and %posttrans errors are downstream of the gated PCR 0
validation, not independent faults.
**6. Current mitigation (reporter's system)**
measure-pcr-validator.ignore=yes # /etc/kernel/cmdline
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**
• 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
--
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]
