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
