On Wed, Nov 04, 2020 at 11:09:22PM +0100, Heinrich Schuchardt wrote:
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.
Right, that goes back to my initial response then. People that contributed the TPM code are cc'ed so they might have a better answer, I'll just repeat myself here. I think the 256b was choosen because it was enough for the basic operations that were implemented.
Types like TPML_PCR_SELECTION contain arrays. Why should we assume that these arrays fit into 256 bytes?
Well in practice they did. The spec used to say TPM2_NUM_PCR_BANKS = 3, so those specific responses were meant to fit in there. The struct is: typedef struct { UINT32 count; TPMS_PCR_SELECTION pcrSelections[TPM2_NUM_PCR_BANKS]; } TPML_PCR_SELECTION;
As far as I understand this is going to change with a new revision and TPM2_NUM_PCR_BANKS will be 16 since newer hardware supports more PCR banks.
Should the logic in lib/tpm-v2.c be wrong, this needs to be fixed before building an EFI protocol upon it.
Why? The functionality it offsers is working *today*. As long as we make sure the added EFI protocol can use a configurable response buffer, acquired by the hardware we can go back and fix lib/tpm-v2.c when we need to. No?
Regards /Ilias
Best regards
Heinrich