Re: [PATCH] tpm-buf: memory-safe allocations

[Jarkko Sakkinen]

On Mon, May 25, 2026 at 01:50:51PM -0400, James Bottomley wrote:
> On Fri, 2026-05-22 at 04:35 +0300, Jarkko Sakkinen wrote:
> > Decouple kzalloc from buffer creation, so that a managed allocation
> > can be
> > used:
> > 
> > 	struct tpm_buf *buf __free(kfree) buf = kzalloc(TPM_BUFSIZE,
> > 						GFP_KERNEL);
> > 	if (!buf)
> > 		return -ENOMEM;
> > 
> > 	tpm_buf_init(buf, TPM_BUFSIZE);
> > 
> > Alternatively, stack allocations are also possible:
> > 
> > 	u8 buf_data[512];
> > 	struct tpm_buf *buf = (struct tpm_buf *)buf_data;
> > 	tpm_buf_init(buf, sizeof(buf_data));
> 
> This isn't really a good idea from a security point of view.  Remember
> the buffer has to be big enough for both the sent and the received
> data.  Today we simply set TPM_BUFSIZE to the maximum amount a TPM
> requires and all the send and receives just work.  If we let callers
> set this size, we're asking for them to get it wrong (or at least
> forget about the receive part) and for us to get a DMA overrun from the
> TPM ... which might be potentially exploitable depending on how it
> occurs (think of an unseal of user chosen data overrunning).

It's one patch so you're free to remark the call sites where this
happens. This is not a majorn concern at all.

> 
> I get the desire to support some of the newer chunked commands, but
> since none of them is yet present in the kernel, why not introduce an
> API that works only for them to avoid the risk of a security cockup in
> existing code?

Multiplying amount of maintenance work with a redundant implemntation
is not something I support.

> 
> Regards,
> 
> James


BR, Jarkko