| Message ID | 20240518113424.13486-1-jarkko@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | tpm: Disable TCG_TPM2_HMAC by default | expand |
On Sat, 2024-05-18 at 14:34 +0300, Jarkko Sakkinen wrote: > Causes performance drop in initialization so needs to be opt-in. > Distributors are capable of opt-in enabling this. Could be also > handled by kernel-command line in the future. > > Reported-by: Vitor Soares <ivitro@gmail.com> > Closes: > https://lore.kernel.org/linux-integrity/bf67346ef623ff3c452c4f968b7d900911e250c3.camel@gmail.com/#t Hey, there's no response on that thread verifying the primary generation is the culprit. Could we at least wait for a reply before taking such drastic action based on surmise? I'd be really surprised if it is primary generation. If I used an RSA primary it would be a problem (My oldest TPM takes a couple of minutes to generate one) but the longest I've seen an EC primary take to generate is still less than a second. James
On Mon May 20, 2024 at 5:50 PM EEST, James Bottomley wrote: > On Sat, 2024-05-18 at 14:34 +0300, Jarkko Sakkinen wrote: > > Causes performance drop in initialization so needs to be opt-in. > > Distributors are capable of opt-in enabling this. Could be also > > handled by kernel-command line in the future. > > > > Reported-by: Vitor Soares <ivitro@gmail.com> > > Closes: > > https://lore.kernel.org/linux-integrity/bf67346ef623ff3c452c4f968b7d900911e250c3.camel@gmail.com/#t > > Hey, there's no response on that thread verifying the primary > generation is the culprit. Could we at least wait for a reply before > taking such drastic action based on surmise? > > I'd be really surprised if it is primary generation. If I used an RSA > primary it would be a problem (My oldest TPM takes a couple of minutes > to generate one) but the longest I've seen an EC primary take to > generate is still less than a second. > > James Nothing is going to happen before rc1 is out, it would be earliest rc2. ECDSA should be always faster than RSA so you're right that it does not necessarily make much sense, unless there are TPM2 chips with only RSA. It might make sense to have at least a command-line option to disable hmac. BR, Jarkko
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index e63a6a17793c..db41301e63f2 100644 --- a/drivers/char/tpm/Kconfig +++ b/drivers/char/tpm/Kconfig @@ -29,7 +29,7 @@ if TCG_TPM config TCG_TPM2_HMAC bool "Use HMAC and encrypted transactions on the TPM bus" - default y + default n select CRYPTO_ECDH select CRYPTO_LIB_AESCFB select CRYPTO_LIB_SHA256
Causes performance drop in initialization so needs to be opt-in. Distributors are capable of opt-in enabling this. Could be also handled by kernel-command line in the future. Reported-by: Vitor Soares <ivitro@gmail.com> Closes: https://lore.kernel.org/linux-integrity/bf67346ef623ff3c452c4f968b7d900911e250c3.camel@gmail.com/#t Fixes: d2add27cf2b8 ("tpm: Add NULL primary creation") Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> --- drivers/char/tpm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)