[PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Stuart Yoder]

On 5/31/23 5:09 PM, Heinrich Schuchardt wrote:
> 
> 
> 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?

In theory there could be old clients from 6+ years ago that were
built to support the 1.0 struct.  But, this seems unlikely
given how much time has passed.

This is exactly why Ilias doesn't want to put support for the 1.0
struct in u-boot.  We don't care about 1.0 clients.

>>
>>>>
>>>> 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.

I'm going to push TCG to publish the errata clarifying this.  Once that
is published the tests will match the spec.

Thanks,
Stuart