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

[Stuart Yoder]

On 6/1/23 1:30 AM, Heinrich Schuchardt wrote:
> 
> 
> Am 1. Juni 2023 01:35:01 MESZ schrieb Stuart Yoder <stuart.yoder at arm.com>:
>>
>>
>> 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
> 
> 
> https://www.trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev9-150513_Public-Review.pdf
> 
> is a draft version using ProtocolVersion = 1.3.  I would assume 1.0 relates to an earlier draft not to a published specification.

In 6.1 the spec says:

   A user of this protocol should call the
   EFI_TCG2_PROTOCOL.GetCapabilities
   operation (Section 6.4) to determine the functionality implemented
   by this interface. There are earlier implementations of this
   protocol that implement a subset of the functions and
   capabilities defined here.

I don't know anything about the earlier implementations, but they
seem to have existed at some point.

The structure version is 1.1:

   Version of the EFI_TCG2_BOOT_SERVICE_CAPABILITY
   structure itself. For this version of the protocol, the Major version
   SHALL be set to 1 and the Minor version SHALL be set to 1.

Thanks,
Stuart