Re: [PATCH 1/3] tpm: Disable TCG_TPM2_HMAC by default

["Jarkko Sakkinen" <jarkko@kernel.org>]

On Tue May 21, 2024 at 3:33 PM EEST, James Bottomley wrote:
> On Tue, 2024-05-21 at 10:10 +0300, Jarkko Sakkinen wrote:
> > This benchmark could be done in user space using /dev/tpm0.
>
> Let's actually try that.  If you have the ibmtss installed, the command
> to time primary key generation from userspace on your tpm is
>
> time tsscreateprimary -hi n -ecc nistp256
>
>
> And just for chuckles and grins, try it in the owner hierarchy as well
> (sometimes slow TPMs cache this)
>
> time tsscreateprimary -hi o -ecc nistp256
>
> And if you have tpm2 tools, the above commands should be:
>
> time tpm2_createprimary -C n -G ecc256
> time tpm2_createprimary -C o -G ecc256

Thanks, I definitely want to try these in my NUC7. I can try both
stacks and it is pretty good test machine because it is old'ish
and slow ;-)

I'm also thinking differently than when I put out this pull request.
I honestly think that it must be weird use case to use TPM with
a machine that dies with a HMAC pipe. It makes no sense to me and
I think we should focus on common sense here.

I could imagine one use case: pre-production hardware that is not
yet in ASIC. But in that case you would probably build your kernel
picking exactly the right options. I mean it is only a default
after all.

I think we could add this:

	default X86 || ARM64

This pretty covers the spectrum where HMAC does make sense by
default. We can always relax it but this does not really take
away the legit user base from the feature.

It would be a huge bottleneck to make HMAC also opt-in because
the stuff it adds makes a lot of sense when build on top. E.g.
the asymmetric key patch set that I sent within early week was
made possible by all this great work that you've done.

So yeah, I'd like to send the above Kconfig changes, but that
is all I want to do this at this point.

> James

BR, Jarkko