On Sun, Mar 23, 2025 at 03:09:08PM +0100, Nicolai Stange wrote:

PCR reads aren't currently authenticated even with CONFIG_TCG_TPM2_HMAC=y
yet.

It is probably desirable though, as e.g. IMA does some PCR reads to form
the cumulative boot digest subsequently extended into PCR 10 (an operation
which *is* authenticated).

Furthermore, a subsequent patch will make IMA to skip certain PCR bank
re-invalidations (which are implemented with extensions) upon kexec based
on the value read back at boot. In order to not weaken the overall
security posture in this case, it will be required to establish the same
level of trust into PCR reads as there is already for the extensions.

Make tpm2_pcr_read() to protect the command with a HMAC auth session,
using the already existing infrastructure.

As the TPM2_PCR_Read command doesn't have any authorizations defined, and
neither of TPM2_SA_ENCRYPT/TPM2_SA_DECRYPT is needed, use TPM2_SA_AUDIT,
even though no auditing functionality is actually being required. Since
the TPM will set TPM2_SA_AUDIT_EXCLUSIVE in its response with this
single-use session, set it upfront so that tpm_buf_check_hmac_response()
would expect it for the HMAC verification.

Now that tpm2_pcr_read() depends on the driver's session infrastructure,
note that the first call to tpm2_pcr_read() at init time gets issued from
  tpm_chip_bootstrap() -> tpm_get_pcr_allocation()
  -> tpm2_get_pcr_allocation() -> tpm2_init_bank_info()
  -> tpm2_pcr_read()
after
  tpm_chip_bootstrap() -> tpm_auto_startup() -> tpm2_auto_startup()
  -> tpm2_sessions_init(),
so there won't be any issues with that.

Signed-off-by: Nicolai Stange <redacted>

Please write a better commit message. There's extra words like 'yet'.

And e.g., subsequent patch means nothing in the commit log.  Please
don't use such terminology.

Not going to waste my life reading this.

BR, Jarkko