Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility
Heinrich Schuchardt
xypron.glpk at gmx.de
Thu Jun 1 00:09:18 CEST 2023
Am 31. Mai 2023 22:40:23 MESZ schrieb Stuart Yoder <stuart.yoder at arm.com>:
>
>
>On 5/31/23 3:10 PM, Heinrich Schuchardt wrote:
>> On 5/31/23 21:37, Stuart Yoder wrote:
>>>
>>> Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
>>> #3. They attempted to clarify in an errata:
>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf
>>>
>>> ...but it is still confusing.
>>>
>>> Ilias and I had discussed the ambiguities, and back in March 2022 I
>>> requested clarification from the TCG workgroup. In cases of
>>> ambiguity TCG frequently will defer to how EDK2 has implemented
>>> a point in the spec.
>>>
>>> Here are my notes following the call with TCG about the intent
>>> of #2 and #3, which was based on their review of the EDK2
>>> implementation:
>>>
>>> a. If a client passes in a Size that is the full size including all
>>> fields including ActivePcrBanks, the return code is SUCCESS and
>>> all fields are populated. [This is a 1.1 client scenario]
>>>
>>> b. If a client passes in a Size that includes all fields up to
>>> and including the vendor ID, the return code is SUCCESS and all
>>> fields up to including the vendor ID are populated. [This is a
>>> 1.0 client scenario, so a populated 1.0 struct is returned]
>>
>> This contradicts the TCG EFI Protocol Specifiction which knows of no 1.0
>> structure but requires:
>>
>> If the input ProtocolCapability.Size <
>> sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) the function will initialize
>> the fields included in ProtocolCapability.Size. The values of the
>> remaining fields will be undefined.
>>
>> We should stick with what is specified.
>>
>> The above requirement is not yet implemented in U-Boot.
>>
>> Could you, please, indicated where the 1.0 structure was ever defined. I
>> could not find any a document linked on
>> https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/
>
>I can't find any public spec with the 1.0 struct.
If it does not exist in a specification, why care about it?
>
>>>
>>> c. If a client passes in a Size that is less than the size up to
>>> and including the vendor ID, the return code is BUFFER_TOO_SMALL
>>> and the Size field is populated with the full size of the struct
>>> supported by the firmware. [This allows a client to determine
>>> whether it is talking to 1.0 or 1.1 firmware]
>>
>> Yes, it is the client's task to check the protocol version and not the
>> firmware's task to guess what the client has in mind.
>>
>> ARM should fix their tests that don't comply with the TCG EFI Protocol
>> Specification and then upstream them to edk-test. U-Boot should not try
>> to work around incorrect vendor tests.
>
>The spec is not clear. And the committee that owns the spec provided
>the clarifications I outlined. They were supposed to provide an errata
>update to publish those clarifications, but it seems somehow that
>didn't happen.
>
>I specifically defined the SCT test spec based on what the committee
>told me:
>https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md
>
>The Arm created tests match what I've been told is the the _intent_ of
>the spec. What is missing is getting TCG to publish errata documenting
>that.
As you wrote above the tests don't relate to a known specification.
Best regards
Heinrich
>
>Thanks,
>Stuart
More information about the U-Boot
mailing list