Re: [PATCH 0/4] Add support for the TPM FF-A start method

Stuart Yoder
2025-02-11T16:09:28Z

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