Issue with TPM kernel code

Issue with TPM kernel code

[Frédéric JOUEN]

[-- Attachment #1.1: Type: text/plain, Size: 656 bytes --]

Good morning All,

 

I have created two issues into the raspberrypi linux github regarding the
TPM driver interface.  

Issues are :

*	https://github.com/raspberrypi/linux/issues/7053
*	https://github.com/raspberrypi/linux/issues/7054

 

For both Phil Elwell redirects me to you.  

How can address these issues in a proper way ?

 

On my side I’m currently working  in SEALSQ France (a WISeKey company).  

We are about to release a new TPM device including PQC features. 

But today we are facing some troubles such as the issues listed above with
using current linux kernel. 

 

Best Regards,

Frederic Jouen

 


[-- Attachment #1.2: Type: text/html, Size: 5233 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4468 bytes --]

Re: Issue with TPM kernel code

[Jarkko Sakkinen]

On Thu, Sep 18, 2025 at 08:50:39AM +0000, Frédéric JOUEN wrote:
> Good morning All,
> 
>  
> 
> I have created two issues into the raspberrypi linux github regarding the TPM
> driver interface. 
> 
> Issues are :
> 
>   ● https://github.com/raspberrypi/linux/issues/7053

For this I'd hope to get some sort of draft of a patch at minimum
(e.g. with RFC tag). It does not have to be fully working if it
shows the problem.

>   ● https://github.com/raspberrypi/linux/issues/7054


I.e. this: https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-Version-1p06_pub.pdf

It can be updated. I don't think that timeout did exist when at
the time this was first implemented i.e. it's an improvement
not a bug fix and thus I'd reconsider this:

static u8 tpm2_ordinal_duration_index(u32 ordinal)
{
	switch (ordinal) {
	/* Startup */
	case TPM2_CC_STARTUP:                 /* 144 */
		return TPM_MEDIUM;

	case TPM2_CC_SELF_TEST:               /* 143 */
		return TPM_LONG;

	case TPM2_CC_GET_RANDOM:              /* 17B */
		return TPM_LONG;

	case TPM2_CC_SEQUENCE_UPDATE:         /* 15C */
		return TPM_MEDIUM;
	case TPM2_CC_SEQUENCE_COMPLETE:       /* 13E */
		return TPM_MEDIUM;
	case TPM2_CC_EVENT_SEQUENCE_COMPLETE: /* 185 */
		return TPM_MEDIUM;
	case TPM2_CC_HASH_SEQUENCE_START:     /* 186 */
		return TPM_MEDIUM;

	case TPM2_CC_VERIFY_SIGNATURE:        /* 177 */
		return TPM_LONG_LONG;

	case TPM2_CC_PCR_EXTEND:              /* 182 */
		return TPM_MEDIUM;

	case TPM2_CC_HIERARCHY_CONTROL:       /* 121 */
		return TPM_LONG;
	case TPM2_CC_HIERARCHY_CHANGE_AUTH:   /* 129 */
		return TPM_LONG;

	case TPM2_CC_GET_CAPABILITY:          /* 17A */
		return TPM_MEDIUM;

	case TPM2_CC_NV_READ:                 /* 14E */
		return TPM_LONG;

	case TPM2_CC_CREATE_PRIMARY:          /* 131 */
		return TPM_LONG_LONG;
	case TPM2_CC_CREATE:                  /* 153 */
		return TPM_LONG_LONG;
	case TPM2_CC_CREATE_LOADED:           /* 191 */
		return TPM_LONG_LONG;

	default:
		return TPM_UNDEFINED;
	}
}


It's quite horrible with all the indirection and everything and
hard to patch.

We'd be better of with something like 

static const struct {
	unsigned long ordinal;
	unsigned logn duration; /* msecs */
} tpm2_duration_map[] = {
	{TPM2_CC_STARTUP, 750},
	{TPM2_CC_SELFTEST, 3000},
	{TPM2_CC_GET_RANDOM, 2000}
	/* ... */
}

And change tpm2_calc_ordinal_duration as:

unsigned long tpm2_ordinal_to_duration(u32 ordinal)
{
	int i;

	for (i = 0; i < ARRAY_SIZE(tpm2_duration_table); i++) {
		if (ordinal == tpm2_duration_map[i].ordinal)
			return tpm2_duration_map[i].duration;
	}

	return TPM2_DURATION_DEFAULT;
}

This essentially drops the chip parameter: as of today we have only
common table from TPM2 and tpm_tis is the only driver that modifies
chip->duration. Further, tpm_tis does this exactly for TPM 1 devices.

If there's ever need to make it laaf driver specific it's easy 
enough to make a copy of the template into something like
'chip->duration_map' but right now there is no such use.

I think this would be a pretty good long-term solution for this
and similar issues.

> 
>  
> 
> For both Phil Elwell redirects me to you. 
> 
> How can address these issues in a proper way ?
> 
>  
> 
> On my side I’m currently working  in SEALSQ France (a WISeKey company). 
> 
> We are about to release a new TPM device including PQC features.
> 
> But today we are facing some troubles such as the issues listed above with
> using current linux kernel.
> 
>  
> 
> Best Regards,
> 
> Frederic Jouen
> 
>  
> 

Polite remark, and this also how vger works: use plain text email.
The list drops HTML mail and thus your original message won't
appear at lore.kernel.org (but since I responded this response
luckily will).

BR, Jarkko

Re: Issue with TPM kernel code

[Jarkko Sakkinen]

On Thu, Sep 18, 2025 at 07:27:58PM +0300, Jarkko Sakkinen wrote:
> Polite remark, and this also how vger works: use plain text email.
> The list drops HTML mail and thus your original message won't
> appear at lore.kernel.org (but since I responded this response
> luckily will).


So apparently I was wrong, so all good:

https://lore.kernel.org/linux-integrity/GVAP278MB0280F83F8CE1884D26A0BA35B116A@GVAP278MB0280.CHEP278.PROD.OUTLOOK.COM/

Perhaps the list settings have been changed. Still plain text
would be the most reasonable choice.

BR, Jarkko