Message-ID: <CAFA6WYM3UA9+TE8L2U5Qd8FZfaGZnbba=QzWU7fEu3LKQVm-tw@mail.gmail.com>
Date: Wed, 12 Feb 2025 13:09:23 +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>
Subject: Re: [PATCH 0/4] Add support for the TPM FF-A start method

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

Powered by blists - more mailing lists