Message-ID: <CAFA6WYM0ANqc--ScYtJFRjOsCCjzO3NX46=F5V=rza_6Q-Q96g@mail.gmail.com>
Date: Thu, 13 Feb 2025 11:01:20 +0530
From: Sumit Garg <sumit.garg@...aro.org>
To: Stuart Yoder <stuart.yoder@....com>
Cc: 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

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

Powered by blists - more mailing lists