| Message ID | 20250210232227.97761-1-stuart.yoder@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for the TPM FF-A start method | expand |
+ Jens Hi Stuart, On Tue, 11 Feb 2025 at 04:52, Stuart Yoder <stuart.yoder@arm.com> 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/. 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? > > 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? Also, is that really a discrete TPM or firmware TPM managed by the firmware? If it supports firmware TPM, I would be interested to see how you plan to handle cases related to secure storage. -Sumit > > The first patch adds an FF-A driver to handle the FF-A messaging when > communicating with a CRB-based TPM secure partition built on FF-A. > The driver is probed when the TPM secure partition is discovered by > the Linux FF-A infrastructure. > > The second patch consolidates the check for idle support in the CRB > driver to one place. > > The third patch defines the new ACPI start method enumeration for > CRB over FF-A. > > The fourth patch adds support for the FF-A ACPI start method to > the TPM crb driver. > > Stuart Yoder (4): > tpm_crb: implement driver compliant to CRB over FF-A > tpm_crb: refactor check for idle support into TPM into inline function > ACPICA: add start method for Arm FF-A > tpm_crb: add support for the Arm FF-A start method > > drivers/char/tpm/Kconfig | 9 ++ > drivers/char/tpm/Makefile | 1 + > drivers/char/tpm/ffa_crb.c | 310 +++++++++++++++++++++++++++++++++++++ > drivers/char/tpm/ffa_crb.h | 30 ++++ > drivers/char/tpm/tpm_crb.c | 81 +++++++++- > include/acpi/actbl3.h | 1 + > 6 files changed, 426 insertions(+), 6 deletions(-) > create mode 100644 drivers/char/tpm/ffa_crb.c > create mode 100644 drivers/char/tpm/ffa_crb.h > > -- > 2.34.1 > >
On Mon, Feb 10, 2025 at 05:22:23PM -0600, Stuart Yoder 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/) > > 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. > > The first patch adds an FF-A driver to handle the FF-A messaging when > communicating with a CRB-based TPM secure partition built on FF-A. > The driver is probed when the TPM secure partition is discovered by > the Linux FF-A infrastructure. > All the FF-A related changes look good to me. Acked-by: Sudeep Holla <sudeep.holla@arm.com>
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@arm.com> 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. >> >> 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. > 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. Thanks, Stuart
On Mon, Feb 10, 2025 at 05:22:23PM -0600, Stuart Yoder 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/) It would bring a whole a lot of clarity to open up acronyms. What are F, F and A? There's quite a few of these in this industry. Also, probably you could take the spec out of parentheses and use double colon. BR, Jarkko
On 2/11/25 3:07 PM, Jarkko Sakkinen wrote: > On Mon, Feb 10, 2025 at 05:22:23PM -0600, Stuart Yoder 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/) > > > It would bring a whole a lot of clarity to open up acronyms. > What are F, F and A? There's quite a few of these in this > industry. > > Also, probably you could take the spec out of parentheses and > use double colon. Will do this in v2. Stuart
On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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 > >
On 2/12/25 1:39 AM, Sumit Garg wrote: > On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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
+ Rob On Thu, 13 Feb 2025 at 03:25, Stuart Yoder <stuart.yoder@arm.com> wrote: > > > > On 2/12/25 1:39 AM, Sumit Garg wrote: > > On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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
On 2/12/25 11:31 PM, Sumit Garg wrote: > + Rob > > On Thu, 13 Feb 2025 at 03:25, Stuart Yoder <stuart.yoder@arm.com> wrote: >> >> >> >> On 2/12/25 1:39 AM, Sumit Garg wrote: >>> On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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. Yes, you could do this. But, then the TPM CRB drivers in all the ACPI-based OSes (Linux, Windows) and hypervisors need to be taught this new method of discovery. Adding new start methods is reasonably straightforward, but changing the basic discovery mechanism is a much bigger change. > But if we still want to overload ACPI or DT with the > discoverable firmware bits then it seems like an overkill here. I think it would make sense to do ACPI based discovery or FF-A based discovery, but doing both I think would be overkill. For ease of OS integration ACPI is the way to go. And, potentially device tree in the future. Thanks, Stuart
On Thu, Feb 13, 2025 at 09:19:58AM -0600, Stuart Yoder wrote: > > > On 2/12/25 11:31 PM, Sumit Garg wrote: > > + Rob > > > > On Thu, 13 Feb 2025 at 03:25, Stuart Yoder <stuart.yoder@arm.com> wrote: > > > > > > > > > > > > On 2/12/25 1:39 AM, Sumit Garg wrote: > > > > On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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. > > Yes, you could do this. But, then the TPM CRB drivers in all the > ACPI-based OSes (Linux, Windows) and hypervisors need to be > taught this new method of discovery. Adding new start methods is > reasonably straightforward, but changing the basic discovery > mechanism is a much bigger change. We will be teaching every other OS or hypervisor about FF-A communication regardless. So it's rather about if we want to do it properly leveraging auto discovery mechanisms supported by FF-A or not. > > > But if we still want to overload ACPI or DT with the > > discoverable firmware bits then it seems like an overkill here. > > I think it would make sense to do ACPI based discovery or FF-A > based discovery, but doing both I think would be overkill. For > ease of OS integration ACPI is the way to go. And, potentially > device tree in the future. Encoding firmware bits in ACPI/DT can be seen as an easy upstream path in the shorter run. But when the ACPI/DT becomes overloaded with information that has to be passed from firmware to the OS rather than purely describing hardware to the OS, it's ABI maintainability becomes complex. We are already dealing with DT ABI compatibility challenges especially the forward compatibility, so let's not make it even worse with firmware information that can be discovered automatically. The other benefit of auto discovery is that platform enablement becomes really smooth. Once the firmware starts supporting a particular feature like TPM over FF-A then the OS can discover and support it. -Sumit
On 2/16/25 11:17 PM, Sumit Garg wrote: > On Thu, Feb 13, 2025 at 09:19:58AM -0600, Stuart Yoder wrote: >> >> >> On 2/12/25 11:31 PM, Sumit Garg wrote: >>> + Rob >>> >>> On Thu, 13 Feb 2025 at 03:25, Stuart Yoder <stuart.yoder@arm.com> wrote: >>>> >>>> >>>> >>>> On 2/12/25 1:39 AM, Sumit Garg wrote: >>>>> On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@arm.com> 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@arm.com> 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. >> >> Yes, you could do this. But, then the TPM CRB drivers in all the >> ACPI-based OSes (Linux, Windows) and hypervisors need to be >> taught this new method of discovery. Adding new start methods is >> reasonably straightforward, but changing the basic discovery >> mechanism is a much bigger change. > > We will be teaching every other OS or hypervisor about FF-A > communication regardless. So it's rather about if we want to do it > properly leveraging auto discovery mechanisms supported by FF-A or not. > >> >>> But if we still want to overload ACPI or DT with the >>> discoverable firmware bits then it seems like an overkill here. >> >> I think it would make sense to do ACPI based discovery or FF-A >> based discovery, but doing both I think would be overkill. For >> ease of OS integration ACPI is the way to go. And, potentially >> device tree in the future. > > Encoding firmware bits in ACPI/DT can be seen as an easy upstream path > in the shorter run. But when the ACPI/DT becomes overloaded with > information that has to be passed from firmware to the OS rather than > purely describing hardware to the OS, it's ABI maintainability becomes > complex. We are already dealing with DT ABI compatibility challenges > especially the forward compatibility, so let's not make it even worse > with firmware information that can be discovered automatically. The TCG defined ACPI table has the following: -Physical address of the TPM -Start method -Start method specific parameters -event log address This has been in place 8+ years and this is what OSes expect. The start method advertises the mechanism a driver uses to signal the TPM that something has changed in the CRB, and this allows different types of TPM implementations: -memory mapped -signal via ACPI -signal via ARM SMC (legacy) -signal via Pluton mailbox -signal via FF-A I don't see this as overloading the ACPI table, it's just what the OS needs to know. The TPM does not know (and should not know) the address of the event log. An FF-A based TPM has no way to know this. I don't see how changing TPM discovery to be via FF-A directly would improve maintainability. > The other benefit of auto discovery is that platform enablement becomes > really smooth. Once the firmware starts supporting a particular feature > like TPM over FF-A then the OS can discover and support it. If we added new CRB/FF-A ABIs to get the CRB physical address, start method specific parameters, event log, it would mean that all OSes and hypervisors need to re-architect their CRB drivers or create new FF-A specific CRB drivers. That will not smooth enablement for TPMs. And I don't see advantages for maintainability. Thanks, Stuart