[PATCH 2/2] efi: Add basic EFI_TCG2_PROTOCOL support
Heinrich Schuchardt
xypron.glpk at gmx.de
Wed Nov 4 23:09:22 CET 2020
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
More information about the U-Boot
mailing list