Message-ID: <e142afd2-38ec-4640-b9be-cb414bccc807@arm.com>
Date: Thu, 13 Feb 2025 09:19:58 -0600
From: Stuart Yoder <stuart.yoder@....com>
To: Sumit Garg <sumit.garg@...aro.org>
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



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.

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

Thanks,
Stuart

Powered by blists - more mailing lists