On 11/4/20 10:06 PM, Ilias Apalodimas wrote: > Hi Heinrich >>> > [...] >>> Why are we using COMMAND_BUFFER_SIZE throughout the TPM code if the >>> required buffer size for commands and responses can be read from the TPM >>> device? >> >> I think the logic is that 256b is enough for the basic commands we needed. >> I can change that here. Get the TPM response during efi_tcg2_register() and >> use that >> for the rest of the code? > > A clarification is needed here, which I forgot on my initial response. > The tpm library in U-boot is using the same buffer and length. > That's the reason I used the same response buffer size. The reply is copied > from the > internal buffer defined in tpm2_get_capability() to our response buffer. > So unless we change the TPM internals changing the EFI part will make no > difference. > That being said I don't mind changing the EFI code since it will be > future-proof, against > the tpm code changes. Thoughts?
My question was not about EFI, it was about the lib/tpm-v2.c's usage of COMMAND_BUFFER_SIZE which would only be adequate if the specification explicitly forbids to implement a TPM with larger responses. Types like TPML_PCR_SELECTION contain arrays. Why should we assume that these arrays fit into 256 bytes? Should the logic in lib/tpm-v2.c be wrong, this needs to be fixed before building an EFI protocol upon it. Best regards Heinrich
