On Tue May 21, 2024 at 4:00 PM EEST, Jarkko Sakkinen wrote: > 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. Patch is out (lore link was not yet available): https://lkml.org/lkml/2024/5/21/583 BR, Jarkko
