On 5/31/23 5:09 PM, Heinrich Schuchardt wrote:
Am 31. Mai 2023 22:40:23 MESZ schrieb Stuart Yoder <stuart.yo...@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
