[FFA] [TPM] CrbControlResponseSize is not set to the correct value in the TpmServiceLib

[eran-c]

Is there an existing issue for this?

• I have searched existing issues

Current Behavior

According to the TCG spec (https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p05p_r14_pub.pdf) at offset 64h from the beginning of each locality address space, there is a CRB register called TPM_CRB_CTRL_RSP_SIZE_x.

This register represents the "size of the response buffer" according to the spec. Note that this is not the size of the response, but the response buffer size that should not change during the lifetime of a system.

In the TpmServiceLib, in the PtpCrbTpmCommand function, this register is initialized properly:
MmioWrite32 ((UINTN)&CrbReg->CrbControlResponseSize, sizeof (CrbReg->CrbDataBuffer));

However, whenever a Start command is received, a HandleCommand function is called which then takes the pointer to an internal copy of this register and sends it to the Tpm2SubmitCommand which, on a normal flow, changes this register's value to the size of the response, which is usually smaller than the expected response buffer size.

Expected Behavior

The CrbControlResponseSize value should not change and should be left equal to sizeof (CrbReg->CrbDataBuffer), which is 0xf80.
Specifically, when calling Tpm2SubmitCommand, we suggest passing InternalTpmCrb->CrbControlResponseSize by value like the other parameters and not returning the response size as an output parameter.
The software side does not look for the response size in this register, it reads the response size from the CRB buffer itself by reading a fixed sized header that includes the current response actual size.

In fact, we recommend changing the name of the field CrbControlResponseSize as well as the field CrbControlCommandSize to
CrbControlResponseBufferSize and CrbControlCommandBufferSize respectively.

Steps To Reproduce

This can be reproduced from the software side, looking at the register value after each call to a Start command and making sure it does not change from the expected value of 0xf80.

Build Environment

- OS(s): Win3
- Tool Chain(s):
- Targets Impacted:

Version Information

Commit: f604a01d2f9a24e744a217d77ff871c505e3c3e3

Urgency

Medium

Are you going to fix this?

Someone else needs to fix it

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

No response