linux-kernel - Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

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: <61e923d6-388b-4cc6-8c26-5581a1e1cc10@arm.com>
Date: Wed, 29 Oct 2025 09:49:04 +0000
From: Ben Horgan <ben.horgan@....com>
To: Yeoreum Yun <yeoreum.yun@....com>
Cc: maz@...nel.org, oliver.upton@...ux.dev, joey.gouly@....com,
 suzuki.poulose@....com, yuzenghui@...wei.com, catalin.marinas@....com,
 will@...nel.org, perlarsen@...gle.com, ayrton@...gle.com,
 linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: arm64: support optional calls of FF-A v1.2

Hi Levi,

On 10/28/25 21:06, Yeoreum Yun wrote:
> Hi Ben,
> 
>>> To use TPM drvier which uses CRB over FF-A with FFA_DIRECT_REQ2,
>>> support the FF-A v1.2's optinal calls by querying whether
>>> SPMC supports those.
>>>
>>> Signed-off-by: Yeoreum Yun <yeoreum.yun@....com>
>>> ---
>>>  arch/arm64/kvm/hyp/nvhe/ffa.c | 19 ++++++++++++++++++-
>>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> index 0ae87ff61758..9ded1c6369b9 100644
>>> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
>>> @@ -646,6 +646,22 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>>>  		ffa_to_smccc_res(res, ret);
>>>  }
>>>
>>> +static bool ffa_1_2_optional_calls_supported(u64 func_id)
>>> +{
>>> +	struct arm_smccc_1_2_regs res;
>>> +
>>> +	if (!smp_load_acquire(&has_version_negotiated) ||
>>> +		(FFA_MINOR_VERSION(FFA_VERSION_1_2) < 2))
>>> +		return false;
>>> +
>>> +	arm_smccc_1_2_smc(&(struct arm_smccc_1_2_regs) {
>>> +		.a0 = FFA_FEATURES,
>>> +		.a1 = func_id,
>>> +	}, &res);
>>> +
>>> +	return res.a0 == FFA_SUCCESS;
>>> +}
>>> +
>>>  /*
>>>   * Is a given FFA function supported, either by forwarding on directly
>>>   * or by handling at EL2?
>>> @@ -678,12 +694,13 @@ static bool ffa_call_supported(u64 func_id)
>>>  	case FFA_NOTIFICATION_SET:
>>>  	case FFA_NOTIFICATION_GET:
>>>  	case FFA_NOTIFICATION_INFO_GET:
>>> +		return false;
>>>  	/* Optional interfaces added in FF-A 1.2 */
>>>  	case FFA_MSG_SEND_DIRECT_REQ2:		/* Optional per 7.5.1 */
>>>  	case FFA_MSG_SEND_DIRECT_RESP2:		/* Optional per 7.5.1 */
>>>  	case FFA_CONSOLE_LOG:			/* Optional per 13.1: not in Table 13.1 */
>>
>> Looking at table 13.54 in the FF-A 1.2 spec FFA_CONSOLE_LOG is only supported in secure FF-A
>> instances and not from the normal world.
> 
> Thanks. in that case, we can return false for FFA_CONSOLE_LOG
> unconditionally.
> 
>>
>>>  	case FFA_PARTITION_INFO_GET_REGS:	/* Optional for virtual instances per 13.1 */
>>> -		return false;
>>> +		return ffa_1_2_optional_calls_supported(func_id);
>>>  	}
>>
>> I don't think that an smc call here is the right thing to do. This changes this from a light
>> weight deny list to an extra smc call for each ffa_msg_send_direct_req2 from the driver.
>>
>> Instead, I would expect this patch just to remove FFA_MSG_SEND_DIRECT_REQ2 from the deny list
>> and rely on the TPM driver to use FFA_FEATURES to check whether it's supported.
>>
>> So, just this change:
>>
>> @@ -679,7 +679,6 @@ static bool ffa_call_supported(u64 func_id)
>>         case FFA_NOTIFICATION_GET:
>>         case FFA_NOTIFICATION_INFO_GET:
>>         /* Optional interfaces added in FF-A 1.2 */
>> -       case FFA_MSG_SEND_DIRECT_REQ2:          /* Optional per 7.5.1 */
>>         case FFA_MSG_SEND_DIRECT_RESP2:         /* Optional per 7.5.1 */
>>         case FFA_CONSOLE_LOG:                   /* Optional per 13.1: not in Table 13.1 */
>>         case FFA_PARTITION_INFO_GET_REGS:       /* Optional for virtual instances per 13.1 */
>>
>> Am I missing something?
> 
> Nope. I think you don't think you miss anything and
> I also think about it.
> 
> But, I'm not sure about "support" means in the pkvm about FF-A.
> Anyway unless the SPMC doesn't support the specific FF-A ABI,
> I don't know that's meaningful to return "TRUE" in here.
> IOW, suppose pkvm returns supports of  FFA_MSG_SEND_DIRECT_REQ2
> but user receive when it calls FFA_MSG_SEND_DIRECT_REQ2 with NOT SUPPORTED.

As I understand it, the ffa_call_supported() is used in two places:
1. To return NOT SUPPORTED to an FFA_FEATURE call for ffa calls that are
on the deny list.
2. To block ffa calls if they are on the deny list.

For both your patch and just removing FFA_MSG_SEND_DIRECT_REQ2 from the
denylist I think the behaviour is the same.

If FFA_MSG_SEND_DIRECT_REQ2 is not supported at the spmc then:
a) an FFA_FEATURE call will return not supported
b) an FFA_MSG_SEND_DIRECT_REQ2 will return not supported

> 
> I'm not sure this inconsistency is allowed or not so as a defensive
> perspective.
> 
> If that allows, I don't have a any special comment for this.
> 
> Thanks!
> 
> --
> Sincerely,
> Yeoreum Yun

-- 
Thanks,

Ben