Re: [PATCH 08/12] xen/arm: ffa: Fix FFA_FEATURES validation

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jens,

> On 11 Feb 2026, at 14:34, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
> 
> Hi Bertrand,
> 
> On Wed, Feb 11, 2026 at 12:27 PM Bertrand Marquis
> <Bertrand.Marquis@xxxxxxx> wrote:
>> 
>> Hi Jens,
>> 
>>> On 11 Feb 2026, at 09:17, Jens Wiklander <jens.wiklander@xxxxxxxxxx> wrote:
>>> 
>>> Hi Bertrand,
>>> 
>>> On Tue, Feb 3, 2026 at 6:38 PM Bertrand Marquis
>>> <bertrand.marquis@xxxxxxx> wrote:
>>>> 
>>>> FFA_FEATURES currently accepts non-zero input properties (w2-w7) from
>>>> guests and advertises several ABIs unconditionally, even when firmware
>>>> support is missing or when the ABI is physical-instance-only. This can
>>>> mislead guests about what Xen can actually provide and violates FF-A
>>>> calling conventions. Some SPMCs (Hafnium v2.14 or earlier) also fail to
>>>> report FFA_RX_ACQUIRE despite supporting it.
>>>> 
>>>> Update FFA_FEATURES validation to match spec and firmware support:
>>>> - reject non-zero w2-w7 input properties with INVALID_PARAMETERS
>>>> - reject 64-bit calling conventions from 32-bit guests with NOT_SUPPORTED
>>>> - return NOT_SUPPORTED for physical-instance-only ABIs
>>>> (FFA_NOTIFICATION_BITMAP_{CREATE,DESTROY}, FFA_RX_ACQUIRE)
>>>> - advertise FFA_INTERRUPT as supported
>>>> - gate message ABIs on firmware support:
>>>> - FFA_MSG_SEND_DIRECT_REQ_{32,64}
>>>> - FFA_MSG_SEND_DIRECT_REQ2 (also requires FF-A 1.2 negotiation)
>>>> - FFA_MSG_SEND2 (or VM-to-VM enabled)
>>>> - report MEM_SHARE_{32,64} only when FFA_MEM_SHARE_64 is supported
>>>> - stop advertising FFA_MSG_YIELD (not implemented)
>>>> 
>>>> Update firmware probing: drop FFA_MEM_SHARE_32 checks (deprecated) and
>>>> add FFA_RX_ACQUIRE to the probed set. If FFA_MSG_SEND2 is reported but
>>>> FFA_RX_ACQUIRE is not, assume RX_ACQUIRE support and warn to work
>>>> around the Hafnium bug.
>>>> 
>>>> Functional impact: guests now see ABI support that reflects firmware
>>>> capabilities and Xen implementation status. When SEND2 is present but
>>>> RX_ACQUIRE is not reported, Xen assumes RX_ACQUIRE support.
>>>> 
>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>>> ---
>>>> xen/arch/arm/tee/ffa.c | 62 +++++++++++++++++++++++++++++++++++++-----
>>>> 1 file changed, 55 insertions(+), 7 deletions(-)
>>>> 
>>>> diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
>>>> index 6de2b9f8ac8e..e9e020bb0cb3 100644
>>>> --- a/xen/arch/arm/tee/ffa.c
>>>> +++ b/xen/arch/arm/tee/ffa.c
>>>> @@ -91,10 +91,10 @@ static const struct ffa_fw_abi ffa_fw_abi_needed[] = {
>>>>    FW_ABI(FFA_PARTITION_INFO_GET),
>>>>    FW_ABI(FFA_NOTIFICATION_INFO_GET_64),
>>>>    FW_ABI(FFA_NOTIFICATION_GET),
>>>> +    FW_ABI(FFA_RX_ACQUIRE),
>>>>    FW_ABI(FFA_RX_RELEASE),
>>>>    FW_ABI(FFA_RXTX_MAP_64),
>>>>    FW_ABI(FFA_RXTX_UNMAP),
>>>> -    FW_ABI(FFA_MEM_SHARE_32),
>>>>    FW_ABI(FFA_MEM_SHARE_64),
>>>>    FW_ABI(FFA_MEM_RECLAIM),
>>>>    FW_ABI(FFA_MSG_SEND_DIRECT_REQ_32),
>>>> @@ -240,19 +240,39 @@ static void handle_features(struct cpu_user_regs 
>>>> *regs)
>>>>    struct ffa_ctx *ctx = d->arch.tee;
>>>>    unsigned int n;
>>>> 
>>>> +    /*
>>>> +     * Xen does not accept any non-zero FFA_FEATURES input properties from
>>>> +     * VMs. The spec only defines w2 input properties for 
>>>> FFA_MEM_RETRIEVE_REQ
>>>> +     * (NS-bit negotiation for SP/SPMC) and FFA_RXTX_MAP (buffer size and
>>>> +     * alignment), so w2 must be MBZ for our callers.
>>>> +     */
>>> 
>>> The spec (version 1.2) lists them as SBZ, except for w2, which is MBZ,
>>> for Feature IDs.
>> 
>> Very true, this should only check w2 which is anyway defined as MBZ when
>> not used.
>> w3-w7 were MBZ in previous versions of FF-A but are in fact SBZ in 1.2 so
>> we should ignore them
>> 
>>> However, if we're to return an error, invalid parameters is a better choice.
>> 
>> In fact the spec is actually saying the following:
>> If the FF-A interface or feature that was queried is not implemented or 
>> invalid,
>> the callee completes this call with an invocation of the FFA_ERROR interface
>> with the NOT_SUPPORTED error code.
>> 
>> So there is no case for INVALID_PARAMETER.
> 
> You're right.
> 
>> 
>> So in fact i should:
>> - return NOT_SUPPORTED if w2 is not 0
>> - ignore w3-w7
>> 
>> Can you confirm that you have the same reading of the spec than me ?
> 
> The 1.2 spec only says this w2 is MBZ for Feature IDs, and that w2 is
> SBZ for FFA_RXTX_MAP. The 1.3 spec says the same, except that in Table
> 13.14: Feature IDs and properties table, it lists w2 as SBZ.
> 
> Note that FFA_MEM_RETRIEVE_REQ has bits defined in w2, and the unknown
> bits are SBZ.
> 
> Based on that, I'm inclined to keep it simple and ignore w2-w7.

That would make sense, I agree.
I will check why FF-A ACS was failing when i did not have this and if it still 
the case
and come back to you if ignoring is not acceptable (with a reason).

Cheers
Bertrand