efi: support AMD TSME and HP pre-OS PCR measurements

[ebrig]

Summary

Some AMD firmware measures TSME configuration during pre-OS boot, including after the PCR2 EV_SEPARATOR or in PCR7. With the relevant HP BIOS settings enabled, firmware also measures the SVM and pre-boot DMA protection configuration in PCR7. Without these measurements, generated EFI PCR profiles can diverge from the TPM values and prevent a resealed key from unlocking normally.

This change:

• detects TSME status from the AMD PSP sysfs attribute and HP DMA measurement settings from hp-bioscfg, rather than taking the expected values from the event log;
• checks the corresponding event data and digests against those settings and uses them to generate PCR profiles;
• handles the AMD TSME event in its supported pre-OS positions in PCR2 or PCR7;
• requires HP's PCR7 configuration event when the firmware settings indicate it should be measured, and checks its data, digest, and ordering;
• requires an observed OS boundary for post-separator PCR2 measurements, so a truncated log is not treated as valid; and
• applies the same measurement rules in profile generation and preinstall validation.

The Linux ccp driver does not expose the HSTI bit indicating whether TSME measurement is supported. The TSME event is therefore validated when present, but its presence cannot be required from the available platform information.

Hardware validation

Tested on an HP ZBook Ultra G1a 14 inch Mobile Workstation PC with BIOS X89 01.05.07 (2026-05-05), using:

• SVM CPU Virtualization: Enable
• DMA protection: Enable
• Pre-boot DMA protection: All PCIe devices
• Measure Additional DMA Settings: PCR7

After resealing with the patched package, TPM-passphrase unlock succeeded across a reboot. After the September 15 changes, generated PCR2 and PCR7 values were checked against the live TPM on the affected hardware.

Tests on rebased branch

• GOTOOLCHAIN=go1.23.12 ./run-tests --no-expensive-cryptsetup-tests (WSL; passed; TPM simulator tests were not enabled and expensive cryptsetup tests were disabled)
• GOTOOLCHAIN=go1.23.12 go test -count=1 ./efi ./efi/preinstall ./internal/efi (WSL)
• GOTOOLCHAIN=go1.23.12 go build ./... (WSL)
• GOTOOLCHAIN=go1.23.12 go vet ./efi ./efi/preinstall ./internal/efi (WSL)

[ebrig]

@chrisccoulson @valentindavid, would either of you be able to review this when you have a chance?

[frederic-hoerni]

Hi @ebrig , thank you for this PR.

Could you please send the BIOS measurement of your platform (/sys/kernel/security/tpm0/binary_bios_measurements), so that we can get the full picture?

Could you please also agree on the Canonical contributor licence agreement?

[ironhalik]

I implemented this PR on my AMD Thinkpad x13 g3. Works well.

[ironhalik]

@ebrig could you continue this PR? Or would it be ok if I took over via a new PR?

[ebrig]

Thanks, @frederic-hoerni. I’ve signed the Canonical contributor licence agreement.

Attached is a gzip-compressed copy of the requested raw binary_bios_measurements log from the HP ZBook Ultra G1a with BIOS X89 01.05.07 and the firmware configuration described in this PR.

binary_bios_measurements.gz

SHA-256 of the uncompressed log:

94b00512b68eae0cef26fe4c3f6aee036f66140a6687e4dd091b9b8efab0915f

@ironhalik, thank you for testing this on the AMD ThinkPad X13 Gen 3. Yes, I’m continuing this PR, so there’s no need to open a replacement PR.

The PR is ready for continued review. Please let me know if any additional logs, tests, or changes would help.

[pkit]

@ebrig looks better than my change. Works well on my hardware (Thinkpad P14s Gen 6 AMD)

[pkit]

@frederic-hoerni @ebrig the vendor PCR2 event after separator is a TSME: on/off measurement in the new AMD AI cpus.
I disassembled the firmware on multiple AMD laptops to verify.

[frederic-hoerni]

@ebrig, could you please rebase your branch on top of master?

[valentindavid]

I feel like those should be detected not from reading the event log, but from the preinstall checks in efi/preinstall/check_host_security_amd.go. Then it should be verified it is present when expected from the checks of event logs.

Also do we know how the measurement of TSME configuration looks like? It would be better to verify the value in the checks, and generate the expected value from the policy generation.

[ebrig]

Addressed. The preinstall checks now derive the TSME state and HP DMA measurement configuration from sysfs, validate the corresponding event data and digests, and use those independently detected values for profile generation.

Linux does not currently expose the HSTI bit that indicates whether TSME measurement is supported, so the TSME event is validated when present, but its presence cannot be required. I also verified on the affected hardware that the generated PCR2 and PCR7 values match the live TPM.

[ebrig]

@valentindavid I’ve rebased this on current master and updated the implementation in response to your September 15 feedback. Would you be able to take another look when you have a chance?