PCR7 profile expects a `db` `EV_EFI_VARIABLE_AUTHORITY` measurement that some firmware never performs, making TPM unlock impossible

[2atbas]

Summary

On an MSI MAG B850 TOMAHAWK MAX WIFI, Ubuntu Core 26 installs and seals successfully, but every subsequent boot fails to unlock and falls back to the recovery key.

The cause is a single measurement: secboot's generated PCR7 profile contains an EV_EFI_VARIABLE_AUTHORITY extend for the db entry that authorised shim. This firmware does not perform that measurement, so the predicted PCR7 value can never match the measured one.

secboot already tolerates other firmware variations in PCR7 (WithAllowInsufficientDmaProtection, and the user-mode/deployed-mode branch pair). This looks like the same class of problem, and a similar tolerance would make TPM-backed FDE usable on this hardware.

Environment

Board	MSI MAG B850 TOMAHAWK MAX WIFI (MS-7E62)
Firmware	2.A62, 2026-06-29 (latest available)
TPM	AMD fTPM 2.0
OS	Ubuntu Core 26, ubuntu-core-26-amd64, grade signed
snapd	2.76.1 (also reproduced on 2.75.2)
Snaps	pc-kernel 3419, pc 227, core26 380
Secure Boot	enabled; SetupMode=0, AuditMode=0, DeployedMode=0

Symptom

Installation completes, sealed-keys contains tpm, and boot-chains is written. The first real run-mode boot then fails:

snap-bootstrap: Error with keyslot "default": cannot recover keys from keyslot:
  incompatible key data role params: invalid PCR policy data:
  cannot complete authorization policy assertions:
  the PCR policy is not authorized for the current configuration
snap-bootstrap: Error with keyslot "default-fallback": <same>
snap-bootstrap: secboot_sb.go:390: successfully activated encrypted device
  "/dev/disk/by-uuid/..." using a fallback activation method

This is fully reproducible: fresh install from a freshly written image, cleared TPM, and it fails on the very first run-mode boot. It is not a resealing regression.

Analysis

Measured PCR7 (from /sys/kernel/security/tpm0/binary_bios_measurements)

EV_EFI_VARIABLE_DRIVER_CONFIG  ccfc4bb32888…  SecureBoot
EV_EFI_VARIABLE_DRIVER_CONFIG  8b0b9e7f39a2…  PK
EV_EFI_VARIABLE_DRIVER_CONFIG  38620385637c…  KEK
EV_EFI_VARIABLE_DRIVER_CONFIG  79ed9f64ea63…  db
EV_EFI_VARIABLE_DRIVER_CONFIG  7492b4f174ae…  dbx
EV_SEPARATOR                   df3f619804a9…
EV_EFI_VARIABLE_AUTHORITY      e8e9578f5951…  SbatLevel
EV_EFI_VARIABLE_AUTHORITY      68bdff38e48c…  MokListRT

Note there is no EV_EFI_VARIABLE_AUTHORITY for db. The firmware loads and verifies shim against db, but never records which entry authorised it. Per the TCG PC Client Platform Firmware Profile it should.

Resulting PCR7 (SHA-256), verified stable across more than ten boots:

C417ABAF8FC7D699F14CD98EB5580803FE9C6D53BE2E91FD2ECBA24EE576C699

PCR4 and PCR12 are likewise stable, and snapd's boot-chains matches the actual asset hashes and kernel command line.

Profile generated by snapd (SNAPD_DEBUG=1, secboot_tpm.go:974)

Legacy PCR protection profile:
 BranchPoint(
   Branch 0 {
    ExtendPCR(TPM_ALG_SHA256, 7, ccfc4bb3…)   SecureBoot
    ExtendPCR(TPM_ALG_SHA256, 7, 8b0b9e7f…)   PK
    ExtendPCR(TPM_ALG_SHA256, 7, 38620385…)   KEK
    ExtendPCR(TPM_ALG_SHA256, 7, 79ed9f64…)   db
    ExtendPCR(TPM_ALG_SHA256, 7, 7492b4f1…)   dbx
    ExtendPCR(TPM_ALG_SHA256, 7, df3f6198…)   separator
    BranchPoint(
      Branch 0 {
       ExtendPCR(TPM_ALG_SHA256, 7, 4d4a8e2c…)   <-- never measured by this firmware
       ExtendPCR(TPM_ALG_SHA256, 4, 98a7fb4d…)   shim
       ExtendPCR(TPM_ALG_SHA256, 7, e8e9578f…)   SbatLevel
       ExtendPCR(TPM_ALG_SHA256, 7, 68bdff38…)   MokListRT
       …

Every branch, including the deployed-mode and user-mode variants, contains that extra PCR7 extend.

Identification of the extra digest

4d4a8e2c74133bbdc01a16eaf2dbb5d575afeb36f5d8dfcf609ae043909e2ee9 is the SHA-256 of the UEFI_VARIABLE_DATA structure for variable db (d719b2cb-3d3a-4596-a3bc-dad00e67656f) carrying the full EFI_SIGNATURE_DATA of the Microsoft Corporation Third Party Marketplace Root entry, i.e. the CA that signs Ubuntu's shim. Verified by recomputation against the platform's actual db contents.

Consequence

Replaying the profile's PCR7 extends:

predicted by snapd  43DFB710AA385DD81FA258FF0B66428B08CE12C2131A405BFF08309CC5964FBD
measured on device  C417ABAF8FC7D699F14CD98EB5580803FE9C6D53BE2E91FD2ECBA24EE576C699

The two differ by exactly that one extend, which is why the policy is never authorised.

Request

Primarily: would it be reasonable for the shim load handler to omit the db authority measurement when the platform demonstrably does not produce one, or to generate branches both with and without it, as is already done for user mode versus deployed mode?

Secondarily: a sanity check at seal time would help. PCR7 is largely independent of the boot mode here, and we measured the identical value (C417ABAF…) during the install-mode boot and during run-mode boots. Comparing the predicted PCR7 against the value the TPM actually holds, and warning when they differ, would turn a silent failure into an immediate one. As it stands the install seals a policy that provably can never be satisfied, reports success, and the problem only surfaces on the next boot, when a recovery key is already needed to get back in.

Reproduction

1. Install Ubuntu Core 26 on the hardware above, with a cleared TPM and Secure Boot enabled
2. Installation succeeds and seals (sealed-keys = tpm)
3. Reboot into run mode
4. Unlock fails with the error above and falls back to the recovery key, on every boot

[frederic-hoerni]

Thank you for this clear and detailed report. However I don't feel secboot has any issue there, as the TCG PC Client Platform Firmware Profile Specification requires this db measurement. Could you report the issue to your firmware vendor?