[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <D1EL6195XVCO.1T6R5B5AYTQQZ@kernel.org>
Date: Mon, 20 May 2024 18:44:24 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "James Bottomley" <James.Bottomley@...senPartnership.com>,
<linux-integrity@...r.kernel.org>
Cc: <keyrings@...r.kernel.org>, "Vitor Soares" <ivitro@...il.com>, "Peter
Huewe" <peterhuewe@....de>, "Jason Gunthorpe" <jgg@...pe.ca>, "open list"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tpm: Disable TCG_TPM2_HMAC by default
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@...il.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
Powered by blists - more mailing lists