Add support for the TPM FF-A start method

The Arm specification TPM Service CRB over FF-A specification defines the FF-A messages to interact with a CRB-based TPM implemented as an FF-A secure partition.

Spec URL:
https://developer.arm.com/documentation/den0138/latest/

This driver is probed when a TPM Secure Partition is discovered by the FF-A subsystem. It exposes APIs used by the TPM CRB driver to send notifications to the TPM.

Signed-off-by Stuart Yoder <[email protected]>

---
 drivers/char/tpm/Kconfig   |   9 ++
 drivers/char/tpm/Makefile  |   1 +
 drivers/char/tpm/ffa_crb.c | 310 +++++++++++++++++++++++++++++++++++++
 drivers/char/tpm/ffa_crb.h |  30 ++++

Quoted 12 lines · Stuart Yoder

The Arm specification TPM Service CRB over FF-A specification defines the FF-A messages to interact with a CRB-based TPM implemented as an FF-A secure partition.

Spec URL:
https://developer.arm.com/documentation/den0138/latest/

This driver is probed when a TPM Secure Partition is discovered by the FF-A subsystem. It exposes APIs used by the TPM CRB driver to send notifications to the TPM.

Quoted 6 lines

Signed-off-by Stuart Yoder <[email protected]>

---
  drivers/char/tpm/Kconfig   |   9 ++
  drivers/char/tpm/Makefile  |   1 +
  drivers/char/tpm/ffa_crb.c | 310 +++++++++++++++++++++++++++++++++++++
  drivers/char/tpm/ffa_crb.h |  30 ++++

Let's use tpm_ prefix for these.

Add TPM start method for Arm FF-A defined in the TCG ACPI specification v1.4.

Quoted 3 lines · Stuart Yoder

Add TPM start method for Arm FF-A defined in the TCG ACPI specification v1.4.

ACPICA changes require (at least) a pull request to be submitted to the upstream ACPICA project on GitHub from where the changes get pulled into the kernel along with other changes.

If such a pull request is already created, please resend the Linux patch with a link pointing to that pull request to inform the maintainer about the same so that it helps in the review of the patches here.

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.

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

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 4 lines

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?

Quoted 5 lines

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.

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 9 lines

Quoted 6 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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

Quoted 32 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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?

Quoted 40 lines · Sumit Garg

Quoted 38 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 5 lines

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.

+ Rob

Quoted 44 lines · Stuart Yoder

Quoted 40 lines · Sumit Garg

Quoted 38 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 56 lines · Sumit Garg

+ Rob

Quoted 44 lines · Stuart Yoder

Quoted 40 lines · Sumit Garg

Quoted 38 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 64 lines · Stuart Yoder

Quoted 56 lines · Sumit Garg

+ Rob

Quoted 44 lines · Stuart Yoder

Quoted 40 lines · Sumit Garg

Quoted 38 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 84 lines · Sumit Garg

Quoted 64 lines · Stuart Yoder

Quoted 56 lines · Sumit Garg

+ Rob

Quoted 44 lines · Stuart Yoder

Quoted 40 lines · Sumit Garg

Quoted 38 lines · Stuart Yoder

Hi Sumit,

Quoted 6 lines · Sumit Garg

+ Jens

Hi Stuart,

Quoted 1 line · Stuart Yoder

Quoted 8 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

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

Quoted 3 lines · Stuart Yoder

I don't see how changing TPM discovery to be via FF-A directly would improve maintainability.

You are considering ACPI at this point but when people want to use this TPM over FF-A on a platform using DT then it will require corresponding DT bindings. After that each platform has to enable TPM over FF-A in their corresponding ACPI/DT. All that won't be needed with auto discovery over FF-A.

Hi Sumit,

Quoted 10 lines · Sumit Garg

Quoted 3 lines · Stuart Yoder

I don't see how changing TPM discovery to be via FF-A directly would improve maintainability.

You are considering ACPI at this point but when people want to use this TPM over FF-A on a platform using DT then it will require corresponding DT bindings. After that each platform has to enable TPM over FF-A in their corresponding ACPI/DT. All that won't be needed with auto discovery over FF-A.

I hear you and completely agree. However, someone thought it was a good idea to align with other start methods and duplicate information in the TCG ACPI specification. This is definitely a bad idea, as it may contradict the firmware. All we needed was a simple flag to indicate whether FF-A is the start method.

It sounds like a classic case of misalignment between specification authors and practical implementation needs. Instead of a simple flag to indicate FF-A as the start method, duplicating information in the TCG ACPI specification seems unnecessary and potentially problematic—especially if it risks conflicting with firmware behavior.

Anyway, I can't comment on how we ended up here, but this seems to be the reality.

Quoted 8 lines · Sudeep Holla

Hi Sumit,

Quoted 5 lines · Sumit Garg

Quoted 3 lines · Stuart Yoder

I don't see how changing TPM discovery to be via FF-A directly would improve maintainability.

Quoted 5 lines

Quoted 5 lines

You are considering ACPI at this point but when people want to use this TPM over FF-A on a platform using DT then it will require corresponding DT bindings. After that each platform has to enable TPM over FF-A in their corresponding ACPI/DT. All that won't be needed with auto discovery over FF-A.

Yes, we would need a new DT binding.

Quoted 5 lines

I hear you and completely agree. However, someone thought it was a good idea to align with other start methods and duplicate information in the TCG ACPI specification. This is definitely a bad idea, as it may contradict the firmware. All we needed was a simple flag to indicate whether FF-A is the start method.

Do you mean a flag exposed via ACPI? If you do FF-A based discovery you don't even need that. Everything could be determined via an FF-A interface.

Quoted 5 lines

It sounds like a classic case of misalignment between specification authors and practical implementation needs. Instead of a simple flag to indicate FF-A as the start method, duplicating information in the TCG ACPI specification seems unnecessary and potentially problematic—especially if it risks conflicting with firmware behavior.

There is a lot of history, but I think it was simply that ACPI advertisement of an FF-A based TPM seemed like the approach with the least friction. And Linux is not the only target OS.

Quoted 1 line

Anyway, I can't comment on how we ended up here, but this seems to be the reality.

I don't think we are locked into ACPI (or DT) only discovery. It's possible that with a modest delta on top of this patch series that the tpm_crb driver could also probe based on FF-A.

The CRB over FF-A spec (DEN0138) could be extended in a backwards compatible way to expose additional info like the base address of the CRB.

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.

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/)

Quoted 4 lines · Stuart Yoder

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.