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

[Stuart Yoder]

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.

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

Thanks,
Stuart