Message-ID: <Z7iDuwLDA2rFPZK6@sumit-X1>
Date: Fri, 21 Feb 2025 19:16:35 +0530
From: Sumit Garg <sumit.garg@...nel.org>
To: Stuart Yoder <stuart.yoder@....com>
Cc: Sumit Garg <sumit.garg@...aro.org>, linux-integrity@...r.kernel.org,
	jarkko@...nel.org, peterhuewe@....de, jgg@...pe.ca,
	sudeep.holla@....com, rafael@...nel.org, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 0/4] Add support for the TPM FF-A start method

On Mon, Feb 17, 2025 at 10:56:58AM -0600, Stuart Yoder wrote:
> 
> 
> 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@....com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 2/12/25 1:39 AM, Sumit Garg wrote:
> > > > > > On Tue, 11 Feb 2025 at 21:39, Stuart Yoder <stuart.yoder@....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@....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.

The TPM event log is rather something that the firmware should propogate
to the OS rather than the TPM itself. The standard way for firmware to
pass that on is via UEFI [1] but still for non-UEFI compatible platforms
it gets propogated via ACPI/DT from the firmware. As UEFI gets adopted
further in embedded space, the reliance on ACPI/DT will reduce.

[1] Documentation/security/tpm/tpm_event_log.rst

> 
> 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.

> 
> > 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.

We don't need to pass event log over FF-A as UEFI interface is already
there. And we are already adding support for start method over FF-A, so
all I am asking is what significant effort do you see with discovering CRB
pysical address over FF-A.

-Sumit

> 
> Thanks,
> Stuart
> 
> 

Powered by blists - more mailing lists