+ Rob On Thu, 13 Feb 2025 at 03:25, Stuart Yoder <stuart.yoder@xxxxxxx> wrote: > > > > 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. > Can't we rather enable the CRB driver itself probed based on FF-A bus and rather dynamically discover the shared memory buffer via FF-A instead? AFAIU, FF-A provides you with a discovery framework for firmware bits. But if we still want to overload ACPI or DT with the discoverable firmware bits then it seems like an overkill here. > > 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. -Sumit
