Heads GUI cannot reset TPM after tpm_reset_required is set

[filipleple]

Device

NovaCustom NV4x 12th Gen

Firmware version

Dasharo (coreboot+heads) v0.9.3

Brief summary

After flashing Heads v0.9.3 on an NV41PZ / NovaCustom NV4x 12th Gen system and installing Qubes OS, TOTP/HOTP setup asks the user to reset the TPM. Selecting Reset the TPM from the GUI does not reset it. Instead, the GUI shows:

TPM state is inconsistent for sealing/unsealing operations. Reset the TPM first (Options -> TPM/TOTP/HOTP Options -> Reset the TPM).

This is self-referential because the recommended fix is the same GUI action that triggers the error.

Logs suggest that the TOTP unseal failure sets the tpm_reset_required marker, then the GUI reset path is blocked by gate_reseal_with_integrity_report because tpm_reset_required=yes.

Running tpm-reset.sh from the recovery shell works, so the issue appears specific to the GUI reset path rather than TPM hardware access itself.

How reproducible

So far occurred once, needs reproduction

How to reproduce

1. Flash Heads v0.9.3 on an NV41PZ / NovaCustom NV4x 12th Gen system.
2. Use EC firmware version 2026-03-12_d198b64 or equivalent latest EC version for this platform.
3. Install Qubes OS.
4. Boot Heads with debug output enabled.
5. Start TOTP/HOTP setup.
6. When prompted to reset the TPM, select the GUI reset option.
7. Alternatively, go to Options -> TPM/TOTP/HOTP Options -> Reset the TPM.

Expected behavior

Selecting Reset the TPM from the GUI should perform the TPM reset / re-ownership flow, clear the reset-required condition, and allow the user to continue generating or resealing TOTP/HOTP secrets.

The reset action should not be blocked by the same tpm_reset_required marker that it is intended to resolve.

Actual behavior

The GUI reports:

TPM state is inconsistent for sealing/unsealing operations.

Reset the TPM first (Options -> TPM/TOTP/HOTP Options -> Reset the TPM).

The user is returned to the menu and cannot reset the TPM using the GUI. The error points to the same GUI path that triggers the error.

Relevant snippets from debugging:

WARNING: TPM reset required: Unable to unseal TOTP secret from TPM; no TPM primary handle.

update_totp -> gate_reseal_with_integrity_report -> tpm_reset_required
DEBUG: tpm_reset_required: yes
DEBUG: TPM reset marker: PRESENT path=/tmp/secret/tpm_reset_required

show_tpm_totp_hotp_options_menu -> gate_reseal_with_integrity_report -> tpm_reset_required
DEBUG: tpm_reset_required: yes
DEBUG: whiptail_error: ... ERROR: TPM Reset Required ...

The resulting GUI flow appears to be:

TOTP unseal fails
TPM reset marker is set
User selects Reset the TPM in the GUI
GUI enters gate_reseal_with_integrity_report before reset
gate_reseal_with_integrity_report sees tpm_reset_required=yes
GUI shows Reset the TPM first instead of running the reset

Screenshots

No response

Additional context

This happened after a fresh Heads v0.9.3 flash and Qubes OS installation. The user was setting up TOTP/HOTP and was prompted to reset the TPM.

The HOTP error appears to be secondary to the incomplete TPM/TOTP/HOTP initialization:

nonfatal unseal-hotp.sh failure: HOTP counter file not found. If you just reinstalled an OS, you need to reseal the HOTP secret
WARNING: Unable to unseal HOTP secret from TPM

Possible fix direction:

• The Reset the TPM action should probably bypass gate_reseal_with_integrity_report.
• Alternatively, gate_reseal_with_integrity_report should explicitly allow the TPM reset action when tpm_reset_required=yes.
• The gate should prevent unsafe sealing/resealing operations, but it should not prevent the reset operation that resolves the reset-required state.

Solutions you've tried

• Ran tpm2_clear in Qubes dom0. It did not fix the issue.
• Enabled Heads debug output and collected /tmp/debug.log.
• Dropped into the Heads recovery shell and ran tpm-reset.sh. This successfully reset the TPM, which suggests the TPM itself is accessible and that the failure is in the GUI reset flow.

[tlaurion]

@filipleple seems to have been fixed after the release used commits as part of manual testing on my side under e0f0fea, which i never faced in real world but in local tests (how can counter be valid, but totp unseal fail?)

It was discussed since a long while to get rid of tpm2 primary handle hash altogether, which is #2153.

[filipleple]

Great, thanks, we'll pick up the changes in our next release