[GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[Jarkko Sakkinen]

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(-)

Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[Jarkko Sakkinen]

On Fri, Oct 10, 2025 at 08:35:00AM +0300, Jarkko Sakkinen wrote:
> 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
                              "atypical profiles"

> "typical profiles".
 

BR, Jarkko

Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[Linus Torvalds]

On Thu, 9 Oct 2025 at 22:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-next-v6.18-2

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

Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[Jarkko Sakkinen]

On Fri, Oct 10, 2025 at 08:51:09AM -0700, Linus Torvalds wrote:
> On Thu, 9 Oct 2025 at 22:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-next-v6.18-2
> 
> 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.

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.
 
> 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.

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.

> 
> 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".

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


 
> 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.

Very true :-)

 
>              Linus

BR, Jarkko

Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18-2

[pr-tracker-bot]

The pull request you sent on Fri, 10 Oct 2025 08:34:56 +0300:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/84d4e8b613e073d9dfde782c471aedbcefdede6c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html