TPM DEVICE DRIVER: tpmdd-next-v6.18-2

The following changes since commit 5472d60c129f75282d94ae5ad072ee6dfb7c7246:

Merge tag 'trace-v6.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace (2025-10-09 12:18:22 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-next-v6.18-2

for you to fetch changes up to a29ad21b988652dc60aa99c6d3b1e3d52dc69c30:

tpm: Prevent local DOS via tpm/tpm0/ppi/*operations (2025-10-10 08:21:45 +0300)

----------------------------------------------------------------
Hi,

Round #2.

O_EXCL patches will be postponed to 6.19 as they need some restructuring. E.g., there's in-between series regression breaking the user space as lack of O_EXCL flag handling causes obviously unconditional O_EXCL.

As per Chris' feedback, commands fail because it is based on Google's a non-standard proprietary TPM alike implementation. And the issue is not PC Client Profile specific. "typical profiles" are fine when they become "typical profiles".

The null key can be verified with vendor certificate tied keys, and there's challenge-response process using them for certifying any other key by a remote party.

Performance hit on generation aside, if really starting to cut hairs null keys are the most secure option, and it's a non-debatable fact: they have shortest expiration times as seed changes per power cycle.

Based on this TCG_TPM2_HMAC is disabled from defconfig exactly for the sake of the performance issues.

BR, Jarkko

----------------------------------------------------------------
Denis Aleksandrov (1):
tpm: Prevent local DOS via tpm/tpm0/ppi/*operations

Eric Biggers (2):
tpm: Compare HMAC values in constant time
tpm: Use HMAC-SHA256 library instead of open-coded HMAC

Gunnar Kudrjavets (1):
tpm_tis: Fix incorrect arguments in tpm_tis_probe_irq_single

Jarkko Sakkinen (2):
tpm: Disable TPM2_TCG_HMAC by default
tpm: use a map for tpm2_calc_ordinal_duration()

 drivers/char/tpm/Kconfig         |   3 +-
 drivers/char/tpm/tpm-interface.c |   2 +-
 drivers/char/tpm/tpm.h           |   2 +-
 drivers/char/tpm/tpm2-cmd.c      | 127 ++++++++++-----------------------------
 drivers/char/tpm/tpm2-sessions.c | 104 +++++++++-----------------------
 drivers/char/tpm/tpm_ppi.c       |  89 ++++++++++++++++++++-------
 drivers/char/tpm/tpm_tis_core.c  |   4 +-
 include/linux/tpm.h              |   5 +-
 8 files changed, 137 insertions(+), 199 deletions(-)

"atypical profiles"

BR, Jarkko

So I've pulled this, but I'm still unhappy about the explanation.

You tried to explain a one-line single-character change in that pull request, and even in that explanation you spent most effort on dismissing other peoples concerns.

That one-liner would have been - and is - sufficiently explained by "it performs badly and breaks some configurations". There's absolutely no reason to then go on to describe how *you* don't care about those configurations.

But lookie here:

 8 files changed, 137 insertions(+), 199 deletions(-)

that's the actual meat of the pull request, and it gets not a peep of commentary.

I'd also like to point out that Microsoft spent *years* trying to do the "we require certain typical TPM setups", and people complained about their idiocy.

For all I know, they still push that crap.

I would certainly are *NOT* that stupid, and we are not going down that path.

So when it comes to TPM, the rule is not "typical cases work".

The rule is "if it causes problems, we acknowledge them and we avoid them".

Thus the whole "disable TCG_TPM2_HMAC" really doesn't merit this kind of long explanation.

In contrast, the *other* changes are probably much more interesting than that.

Linus

For what it is, most of it comes from:

1. "tpm: use a map for tpm2_calc_ordinal_duration()" Flattened out timeout calculations to a table and increase timeout for TPM2_SelfTest, which addresses longer timeout on Raspeberry Pi.
2. "tpm: Prevent local DOS via tpm/tpm0/ppi/*operations" Caches TPM physical presence interface ACPI functions on first run instead of requesting for every read.

Also:

1. I went through Chris' email because you asked to refer to it.
2. I also spent time re-testing O_EXCL change throughly once more. From my subjective perspective I was exactly trying to address other people's concerns.

That said, I fell off the track and yeah not well delivered agreed.

Maybe I had a bad choice of words but there's no configuration that breaks with anything sold as discrete TPM chips, embedded SoC, fTPM's or anything really. I got the impression of a bug in the wild, other than the perf regression.

I deeply care anything that can be bought with money or even anything that drifts away from a spec manageable amount.

Very true :-)

BR, Jarkko