[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17a5dcd7aceb356587ef7c8f45b0f6359b2d2a91.camel@HansenPartnership.com>
Date: Wed, 22 May 2024 09:35:27 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Vitor Soares <ivitro@...il.com>, Jarkko Sakkinen <jarkko@...nel.org>,
linux-integrity@...r.kernel.org
Cc: keyrings@...r.kernel.org, Peter Huewe <peterhuewe@....de>, Jason
Gunthorpe <jgg@...pe.ca>, Mimi Zohar <zohar@...ux.ibm.com>, David Howells
<dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, James Morris
<jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 1/3] tpm: Disable TCG_TPM2_HMAC by default
On Wed, 2024-05-22 at 09:18 +0100, Vitor Soares wrote:
> On Tue, 2024-05-21 at 08:33 -0400, 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
> >
> > James
> >
> >
>
> Testing on an arm64 platform I get the following results.
>
> hmac disabled:
> time modprobe tpm_tis_spi
> real 0m2.776s
> user 0m0.006s
> sys 0m0.015s
>
> time tpm2_createprimary -C n -G ecc256
> real 0m0.686s
> user 0m0.044s
> sys 0m0.025s
>
> time tpm2_createprimary -C o -G ecc256
> real 0m0.638s
> user 0m0.048s
> sys 0m0.009s
>
>
> hmac enabled:
> time modprobe tpm_tis_spi
> real 8m5.840s
> user 0m0.005s
> sys 0m0.018s
>
>
> time tpm2_createprimary -C n -G ecc256
> real 5m27.678s
> user 0m0.059s
> sys 0m0.009s
>
> (after first command)
> real 0m0.395s
> user 0m0.040s
> sys 0m0.015s
>
> time tpm2_createprimary -C o -G ecc256
> real 0m0.418s
> user 0m0.049s
> sys 0m0.009s
That's interesting: it suggests the create primary is fast (as
expected) but that the TPM is blocked for some reason. Is there
anything else in dmesg if you do
dmesg|grep -i tpm
?
Unfortunately we don't really do timeouts on our end (we have the TPM
do it instead), but we could instrument your kernel with command and
time sent and returned. That may tell us where the problem lies.
Regards,
James
Powered by blists - more mailing lists