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
