@marmarek you need to reset TPM instead of resealing totp from TPM menu

Normally, flow after installing OS is to run oem factory reset / re-ownership.

Doing OEM re-ownership resets TPM as well.

Has it changed at some point? I think the current flow coded in that openQA test worked before (but not sure when, definitely not recently)...

Has it changed at some point? I think the current flow coded in that openQA test worked before (but not sure when, definitely not recently)...

I can check deeper in the next week but that code hasn't changed for 6 years. But string concatenation might be flaky here, while counter clearly doesn't exist here in shared output.

@marmarek I am getting lost in the refactoring under #1935.

Has it changed at some point? I think the current flow coded in that openQA test worked before (but not sure when, definitely not recently)...

Let's clarify here. You previously were able to reinstall an OS without resetting TPM? Can you detail what flow worked before and not anymore on OpenQA?

Unfortunately I don't have logs old enough to answer definitely. But I do have git log that says I needed to added resetting TPM on OS reinstall after some heads update (I don't have exact data of the update anymore, unfortunately, it might be some weeks or even months before that commit date). Before that, it needed only to regenerate HOTP.

Has it changed at some point? I think the current flow coded in that openQA test worked before (but not sure when, definitely not recently)...

The kexec_rollback.txt is created upon creating a TPM LUKS DUK key in default boot, and makes sure and makes sure that what is signed under /boot cannot be rollback (replaced by a signed backup of /boot) when reading TPM counter to tmpdir, and then verifying it's existence through hash verification.

Looking at your qa change, qa checks are reactive to console output. video is not available anymore.

Qa check for default hotp pin, which changed recently when adapting code to nk3, which doesn't use gpg Admin PIN anymore but secret app distinct PIN, so prior check to default PIN might have changed if you switched to nk3.

Then qa check for TPM duk also depending on console output. Was TPM DUK set? A default boot entry set?

The error in OP shows lack of proper string concatenation and validation upon tpm counter read and tpm counter increment.

I will revisit this codepath to Adress it with a simple fix, seperating big PR into sub PR, but addressing this issue distinctively.

Tldr:

• kexec_rollback.txt can be backuped and restored alongside hotp counter in your hacky OS reinstallation QA test, yes. But I'm not sure this is a proper test for OS reinstallation, and a corner use case. If OS is reinstalled, I think Heads should actually do a little more it does (checking tpm unseal op possible, check hotp unseal but if failing check for other /boot kexec* files).
• As if prior test upon OS reinstall use case (not yours), totp unseal would succeed because same firmware parts in pcr2, same pubkey and trusted in pcr6, but then fail because hotp rollback (unsigned). Resealing hotp would fail later because of tpm counter could be different alongside everything else signed under /boot. If a previous default boot config was there, hotp reseal triggered a /boot resign, which read the counter, wrote it, hashed it and signed it alongside everything else /boot.

The simple solution still stands. Resetting tpm after tpm unsealing successful confirms through Tpmtotp that firmware in expected state. Resetting tpm creates new tpm counter and triggers a /boot hash and sign.

What do you think is missing following those explanation? What qa was reacting on and what did your changes meant from your observations? Why a tpm reset upon os reinstall is problematic in your use case simulation?