tpm2-setup: Don't fail if we can't access the TPM due to authorization failure

[DaanDeMeyer]

The TPM might be password/pin protected for various reasons even if
there is no SRK yet. Let's handle those cases gracefully instead of
failing the unit as it is enabled by default.

[github-actions]

Important

An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released.

[yuwata]

Is this for #32898?

[poettering]

Can we please add a structured log message with message id/catalog entry for this?

[poettering]

I'd like to understand better what kind of "lock" you ran into. The error check you are doing here suggests to me that you might have a PIN (aka "authValue") set on the "owner" hierarchy of your TPM? Which is different from "dictionary attack lockout" (aka "DA lockout") which I assumed this was about.

So what is it actually about here? How did you run into this? And do you have debug logs of how tpm2-setup fails on that system?

[DaanDeMeyer]

I'd like to understand better what kind of "lock" you ran into. The error check you are doing here suggests to me that you might have a PIN (aka "authValue") set on the "owner" hierarchy of your TPM? Which is different from "dictionary attack lockout" (aka "DA lockout") which I assumed this was about.

So what is it actually about here? How did you run into this? And do you have debug logs of how tpm2-setup fails on that system?

I don't have debug logs anymore, but the gist of it is that the unit fails with TPM2_RC_BAD_AUTH in tpm2_create_primary(). My cursory googling seemed to indicate this means the TPM is locked, but I guess I was wrong. I'm happy to update the error messages to say that there's a pin on the owner hierarchy. Either way, we should gracefully handle this.

[poettering]

TPM is locked, but I guess I was wrong.

Well, "TPM locked" is a bit vague. Could mean "in DA lockout", or could be "requires a PIN to access"...

[poettering]

But if you turn on debug logs, then you should see more info, that might be helpeful

[poettering]

https://lore.kernel.org/all/e423eaa2-cf2e-6b3f-dff6-61726cb5c0bf@intel.com/T/

Judging by this this is really about a PIN (i.e. authValue) having been set for the "owner" hierarchy, and not about DA lockout.

[poettering]

Or in other words you are running into #22129.

On what kind of system did you run into with btw? How come a password was set for owner auth there?

The proper way to fix this is probably by using ask_password_auto() to simply query for the authValue and then use it. But then again, interactivity might suck

[DaanDeMeyer]

@poettering The TPM has an auth because we don't want anything messing with it. I should have clarified, but I don't actually want this to work, I couldn't care less about setting up an SRK on these systems, I just want tpm2-setup.service to not fail in these cases.

[poettering]

So I think we can merge something like this, but please clean up the wording.

I checked the specs btw: while DA lockout mode is on, any attempt to access a DA protected object results in TPM_RC_LOCKOUT. Any attempt to access an object with an authValue set without an authValue or with a TPM_RC_BAD_AUTH error.

hence, what you are doing here is the latter. We probably should have an explict error message /catalog entry for the lockout thing too, but without testing that we shouldn't add this, hence out of scope for now i guess.

But, please reword this, do not say just "locked", that's too misleading.