linux-kernel - Re: [PATCH] tpm_crb: Add idle support for the Arm 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: <9227d35b-40d6-4faf-910d-ee7de9bbc094@arm.com>
Date: Mon, 25 Aug 2025 17:19:34 -0500
From: Stuart Yoder <stuart.yoder@....com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: linux-integrity@...r.kernel.org, peterhuewe@....de, jgg@...pe.ca,
 sudeep.holla@....com, Prachotan.Bathi@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm_crb: Add idle support for the Arm FF-A start method



On 8/25/25 4:58 PM, Jarkko Sakkinen wrote:
> On Mon, Aug 25, 2025 at 03:59:43PM -0500, Stuart Yoder wrote:
>> According to the CRB over FF-A specification [1], a TPM that implements
>> the ABI must comply with the TCG PTP specification. This requires support
>> for the Idle and Ready states.
>>
>> This patch implements CRB control area requests for goIdle and
>> cmdReady on FF-A based TPMs.
>>
>> The FF-A message used to notify the TPM of CRB updates includes a
>> locality parameter, which provides a hint to the TPM about which
>> locality modified the CRB.  This patch adds a locality parameter
>> to __crb_go_idle() and __crb_cmd_ready() to support this.
>>
>> [1] https://developer.arm.com/documentation/den0138/latest/
>>
>> Signed-off-by: Stuart Yoder <stuart.yoder@....com>
> 
> Perhaps a dummy question but is this "QEMU testable"? I know how
> to bind swtpm to QEMU and make it appear as CRB device on x86-64.
> 
> I don't see much testing happening with these ARM CRB patches,
> and if that works in the first palce  I could probably add
> a new board target to my BR2_EXTERNAL [1].
> 
> I can of course do "negative testing' i.e. that these don't
> break x86 ;-)

Unfortunately this is not currently testable on QEMU.  We are using
the Arm FVP [1], which is also a machine emulator, with the firmware
stack and an fTPM running in TrustZone.  The firmware, fTPM, etc are
not all publicly available yet, but everything is based on open
source projects and the intent is that all the components needed do
test this on FVP will be available at some point.

There is nothing fundamental that would prevent this from running
on QEMU, but just a fair amount of integration and possibly firmware
work.

[1] 
https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms/Arm%20Architecture%20FVPs

Thanks,
Stuart