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