coreboot

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
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

• 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:

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), 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:

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

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