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). 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? Regards, James
