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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fdaa9a58-790f-4839-8db7-1b9a81eb8edf@arm.com>
Date: Wed, 12 Feb 2025 15:55:26 -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>
Subject: Re: [PATCH 0/4] Add support for the TPM FF-A start method



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.

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

Thanks,
Stuart