linux-kernel - Re: [RFC PATCH] tpm: Workaround failed command reception on Infineon devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Zv___74cyROxZSic@earth.li>
Date: Fri, 4 Oct 2024 15:47:27 +0100
From: Jonathan McDowell <noodles@...th.li>
To: Stefan Berger <stefanb@...ux.ibm.com>
Cc: linux-integrity@...r.kernel.org, Jarkko Sakkinen <jarkko@...nel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] tpm: Workaround failed command reception on Infineon
 devices

On Thu, Oct 03, 2024 at 06:25:14PM -0400, Stefan Berger wrote:
> On 10/3/24 5:59 PM, Stefan Berger wrote:
> > On 10/2/24 1:04 PM, Jonathan McDowell wrote:
> > > (I'm still in the process of testing this to confirm it fixes the
> > > errata I've seen, but I wanted to send it out for comments to make sure
> > > it's a reasonable approach.)
> > > 
> > > Some Infineon devices have a issue where the status register will get
> > > stuck with a quick REQUEST_USE / COMMAND_READY sequence. The work around
> > 
> > Did you tell Infineon about it? Maybe they should have a look at their
> > firmware.

I'm in contact with Infineon, and have their errata under NDA.

> > What are the TPMs in your fleet doing? I heared that some TPMs
> > pre-create keys in the background once users requested a few. I would
> > try to create a few primary keys with different combination of key flags
> 
> Actually make this child keys of primary keys:
> 
> > tsscreateprimary
> Handle 80000000
> > while :; do time tsscreate -hp 80000000 -si  -opem pubkey.pem ; cat
> pubkey.pem; done
> 
> This should give a different key every time and maybe key creation time goes
> up at some point...

We're doing a TPM2_CC_CREATE, but as part of a "seal" operation for some
data, rather than full asymmetric key creation. So I don't think this is
likely to be the cause, but it's given me the idea to see if we are
seeing a spike on a particular command - maybe there's something that's
close to the edge on timings that is occasionally going over. Playing
around with bpftrace seems to give useful data so I'll need to
investigate if I can deploy that to do some monitoring.

Our monitoring is running hourly and does the following TPM2
operations (including the in kernel context switching):

TPM2_CC_SELF_TEST
TPM2_CC_GET_CAPABILITY
TPM2_CC_READ_PUBLIC
TPM2_CC_READ_PUBLIC
TPM2_CC_CREATE
TPM2_CC_LOAD
TPM2_CC_CONTEXT_SAVE
TPM2_CC_FLUSH_CONTEXT
TPM2_CC_CONTEXT_LOAD
TPM2_CC_UNSEAL
TPM2_CC_CONTEXT_SAVE
TPM2_CC_FLUSH_CONTEXT
TPM2_CC_CONTEXT_LOAD
TPM2_CC_FLUSH_CONTEXT
TPM2_CC_CONTEXT_SAVE
TPM2_CC_READ_CLOCK
TPM2_CC_GET_CAPABILITY
TPM2_CC_GET_CAPABILITY
TPM2_CC_GET_CAPABILITY
TPM2_CC_GET_CAPABILITY
TPM2_CC_GET_CAPABILITY
TPM2_CC_GET_CAPABILITY
TPM2_CC_READ_PUBLIC

J.

-- 
If I, um, err. Yeah, it probably rounds down. -- Simon Huggins