On 2/12/25 1:39 AM, Sumit Garg wrote:
On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@xxxxxxx> wrote:
Hi Sumit,
On 2/11/25 12:45 AM, Sumit Garg wrote:
+ Jens
Hi Stuart,
On Tue, 11 Feb 2025 at 04:52, Stuart Yoder <stuart.yoder@xxxxxxx> wrote:
These patches add support for the CRB FF-A start method defined
in the TCG ACPI specification v1.4 and the FF-A ABI defined
in the Arm TPM Service CRB over FF-A (DEN0138) specification.
(https://developer.arm.com/documentation/den0138/latest/)
Nice to have a specification standardizing interface to TPM
managed/implemented by the firmware. Care to add corresponding kernel
documentation under Documentation/security/tpm/.
Yes, I can add some documentation there.
BTW, we already have drivers/char/tpm/tpm_ftpm_tee.c, so do you see
possibilities for an abstraction layer on top of communication channel
based on either FF-A or TEE or platform bus?
I think the CRB and OP-TEE based messaging approaches for interacting
with a TZ-based TPM are fundamentally different and I don't see how
to harmonize them through some abstraction.
The OP-TEE TPM protocol copies the TPM command into a temp shared memory
buffer and sends a message to the TPM referencing that buffer.
The CRB uses a permanently shared memory carve-out that in addition
to the command/response data has other fields for locality control,
command control, status, TPM idle, etc. The only 'message' needed is
something to signal 'start'. Any OS that is FF-A aware and has a
CRB driver can simply add a new start method, which is what this
patch series does.
Okay, I see how the CRB driver is closely tied to the ACPI based
systems.
The CRB driver is currently probed based on ACPI, but it fundamentally
doesn't have to be. If there was a DT binding for CRB-based
TPMs the different start methods would be defined there and the
CRB driver could support that.
I was expecting the FF-A based TPM interface to be
independent of ACPI or DT such that it's not constrained by the
hardware description a platform chooses to use. I suppose there will
be a different TPM FF-A driver or spec when someone wants to deploy it
on DT based systems, right?
The CRB is just a shared memory buffer, with some architected semantics
defined by TCG. The basic CRB usage model is that a client puts
something in the CRB, such as the bytes of a TPM command, and then
notifies the TPM that a change was made to the CRB. The CRB over
FF-A spec just defines the message to perform that notification
when FF-A is used.
So, whether the fTPM was advertised via ACPI or DT, it doesn't matter.
The FF-A based interface is only about the the notification messages
needed for the OS driver to tell the TPM that something has changed
in the CRB.
Thanks,
Stuart
