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

[Sudeep Holla]

On Thu, May 14, 2026 at 05:37:38PM +0000, Jamie Nguyen wrote:
> 
> 
> > On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla at 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 at 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.”
> 

I need to check the v1.3-alpha specs to understand/recall the version
negotiations but until v1.2 and the current driver which is v1.2 we don't
have any idea about all these new changes. But since v1.2 already has size
of descriptor, we can and must handle that independently of this new
version (re-)negotiation.

-- 
Regards,
Sudeep