Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS

[Jamie Nguyen <jamien@nvidia.com>]

> On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> 
> On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
>> 
>> 
>>> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
>>> 
>>> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>>>> __ffa_partition_info_get_regs() walks the response with a hardcoded
>>>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
>>>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
>>>> read into buf_sz and then thrown away.
>>>> 
>>>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
>>>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
>>>> strides over half a descriptor at a time and ends up parsing every
>>>> other entry from a slice of two adjacent ones.
>>>> 
>>>> The FF-A spec (v1.2, section 18.5) says that the producer should
>>>> report the descriptor size, and the consumer is supposed to stride by
>>>> that size and ignore any trailing fields it doesn't understand. The
>>>> non-REGS path (__ffa_partition_info_get) does this already, and the
>>>> REGS path should match.
>>>> 
>>>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
>>>> reports something we can't safely walk.
>>>> 
>>> 
>>> Can you check if the issue is addressed in -next by:
>>> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
>> 
>> Thanks for the pointer.  I tested 3974ea193840 on the same hardware
>> that reproduces the bug, but the descriptor-stride issue is still
>> present.
>> 
>> The relevant loop at the end of __ffa_partition_info_get_regs()
>> still has:
>> 
>> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
>> if (buf_sz > sizeof(*buffer))
>> buf_sz = sizeof(*buffer);
>> ...
>> for (idx = 0; idx < nr_desc; idx++, buf++) {
>> ...
>> regs += 3;  /* bug is here */
>> }
>> 
>> With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
> 
> Well why is the firmware sending 48byte entry when 24byte is expected.

We're starting to test with a v1.3 SPMC implementation.  UEFI brings
up its FF-A driver first and negotiates v1.3, which the SPMC then must
keep for the lifetime of the primary VM per DEN0077A v1.2 REL0 section
13.2.2 [0]:

    "Once an FF-A version has been negotiated between a caller and a
     callee, the version may not be changed for the lifetime of the
     calling component.”

When Linux later asks for v1.2 the SPMC stays at 1.3 and emits the
48-byte v1.3 layout: DEN0077A v1.3 ALP4 section 13.9 [1]: "Size of each
descriptor is 48 bytes as per the FF-A v1.3 spec”.

[0]: https://developer.arm.com/documentation/den0077/j
[1]: https://developer.arm.com/documentation/den0077/o

> -- 
> Regards,
> Sudeep