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. 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? > > >> > >> FF-A is a messaging framework for Arm-based systems and in the > >> context of the TPM driver is used to signal 'start' to a CRB-based > >> TPM service which is hosted in an FF-A secure partition running in > >> TrustZone. > > > > Is there any open source implementation for such a secure partition > > managing the TPM? > > Nothing yet, but something I am working towards. > > > Also, is that really a discrete TPM or firmware TPM > > managed by the firmware? > > It could be either. It doesn't matter from the point of view of > the OS CRB driver. For testing this patch series I used an > internal proof-of-concept fTPM with a CRB interface. Okay I see, having a real firmware managed TPM implementation will really unlock the adoption of this specification. > > > If it supports firmware TPM, I would be interested to see how you plan > > to handle cases related to secure storage. > > Yes, this is a challenge and there are various ways it could be > implemented. For example, RPMB or if you have an internal root of > trust with secure storage like an RSE that could play a role. > The RPMB kernel routing is what we have for the OP-TEE based fTPM but I agree there are numerous ways to implement it given the platform's capability. -Sumit > Thanks, > Stuart > >
