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: <96171283-6f2a-45b5-b889-be1bee91678c@immunant.com>
Date: Thu, 30 Oct 2025 14:29:07 +0100
From: Per Larsen <perl@...unant.com>
To: Yeoreum Yun <yeoreum.yun@....com>, Ben Horgan <ben.horgan@....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 Yeoreum,

On 10/29/25 2:36 PM, Yeoreum Yun wrote:
> Hi Ben,
> 
>>
>> 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
>>
> 
> Right! I've missed the FFA_FEATURE handles via default_host_smc_handler().
> As you said, it just a deny list.
> 
> Thanks. I'll change it.
Sorry to jump into the discussion very late. I uploaded a patch set 
which adds support for the FFA_MSG_SEND_DIRECT_REQ2 interface which was 
originally developed for the Android common kernels:

https://lore.kernel.org/all/20251030-host-direct-messages-v1-0-463e57871c8f@google.com/T/#t 


Since there appears to be an upstream use case for this functionality, 
it might be a good building block for the present patch set.

Thanks,
Per