Re: [RFC v2 4/5] tpm: Increase TPM_BUFSIZE to 8kB for chunking support

[Arun Menon]

On Sat, May 09, 2026 at 06:07:11PM +0300, Jarkko Sakkinen wrote:
> On Sat, May 09, 2026 at 05:54:25PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Mar 24, 2026 at 11:42:43PM +0530, Arun Menon wrote:
> > > The size of the command is checked against TPM_BUFSIZE early on before
> > > even sending it to the backend. We therefore need to increase the
> > > TPM_BUFSIZE to allow support for larger commands.
> > > 
> > > For now, 8KB seems sufficient for ML-KEM and ML-DSA algorithms and it is
> > > also order-1 safe.
> > > 
> > > Signed-off-by: Arun Menon <armenon@xxxxxxxxxx>
> > > ---
> > >  drivers/char/tpm/tpm.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > > index 87d68ddf270a7..26c3765fbd732 100644
> > > --- a/drivers/char/tpm/tpm.h
> > > +++ b/drivers/char/tpm/tpm.h
> > > @@ -33,7 +33,7 @@
> > >  #endif
> > >  
> > >  #define TPM_MINOR		224	/* officially assigned */
> > > -#define TPM_BUFSIZE		4096
> > > +#define TPM_BUFSIZE		8192
> > >  #define TPM_NUM_DEVICES		65536
> > >  #define TPM_RETRY		50
> > >  
> > > -- 
> > > 2.53.0
> > > 
> > 
> > Shouldn't this prepend previous patch?
> 
> Also did you remark that tpm_buf would also need changes as it is fixed
> to PAGE_SIZE?

TPM_BUFSIZE can be increased, in its new location include/linux/tpm.h as
per the patch : https://lore.kernel.org/linux-integrity/20260125192526.782202-12-jarkko@xxxxxxxxxx/
and I think that alone will take care of the check if (size > TPM_BUFSIZE)
in tpm_common_write() in drivers/char/tpm/tpm-dev-common.c.

However I was not able to apply the mbox file cleanly on the existing
branches for-next-tpm and for-next-keys. I could apply them cleanly on
the old branch (next). Please guide.

I would only change the TPM_BUFSIZE set in 
[PATCH v9 11/11] tpm-buf: Implement managed allocations to 8192.

> 
> I've made a patch that essentially makes tpm_buf size variable as caller
> does kzalloc:
> 
> https://lore.kernel.org/linux-integrity/20260125192526.782202-12-jarkko@xxxxxxxxxx/
> 
> I'd see this as pretty good long-term solution.

Indeed. 

> 
> BR, Jarkko
> 


Regards,
Arun Menon