From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74F1D438FE5 for ; Fri, 15 May 2026 09:23:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778837023; cv=none; b=YD9+d8eYPl3ZcrLk3M9Ow2Y5CN9AVVZvoFqQP3SQsyQkHkUFyZvuf4rzXrr92bMcC9Ti1oa6PtG6Fms4Z83VM6qUfp1I6vIVbaLO67ein2qzoGoOkWYgKavUK6SWr5tjJG0xMVpULaeEO1NO7rnnCXGK3YztFsobYz+sn6uIRLY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778837023; c=relaxed/simple; bh=AwYB5qEle5qClbxh2ptaO9cbSszb0tZ8KAQzR3xrtPk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZLpEbm6UGAqALoEco9rKzAaKqe21bKUUjZGLAiZquW/e1IOTG+UOj9j26evLS/U/6INV34BtxwTaUZlcOivRn+e1dWXTpS7ZPaubZFNx2O3srbaiweSRKeSh70FNTBWRwp7bm2GfQaUjopAMxQcrw9ZRUe0hEnUJYMU5iaUhptE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PRiDrwmk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PRiDrwmk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7DC31C2BCB0; Fri, 15 May 2026 09:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778837023; bh=AwYB5qEle5qClbxh2ptaO9cbSszb0tZ8KAQzR3xrtPk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PRiDrwmkiDtfDqKCZnBdvNM+X/X8bZozNhS51TzN2KYDyOo/tQHEoMt7oFngw4PH6 TUMC1yPUQtOs7K7rhpY6lgDbOkjPKp9Hv/g+r5xSsSxMt3lJkSbyVyLTfNTZxrqkAe Fxu5HR26xnHnm2hj5w6nWSbQkvAAdT2h7I28bBYQBCYOacgflrbS4y0AVTVk9FGPzS sW/NFev843wgWvF2f/hPM1sHz4wRSK6tF3ibVnnOyIdAX5uUX+5wkmuGiVb//uajmA EeEU5MtEFelR2Eaap9WdsH1+m/sZ4m0M4lqoepoHsb/+lR6obns86zA695ElHPvs8s 1uNrcvoisJQeQ== Date: Fri, 15 May 2026 10:23:40 +0100 From: Sudeep Holla To: Jamie Nguyen Cc: "linux-arm-kernel@lists.infradead.org" , Sudeep Holla , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS Message-ID: <20260515-zippy-notorious-caiman-ea4ec6@sudeepholla> References: <20260513032800.68807-1-jamien@nvidia.com> <20260513-tremendous-conscious-sunfish-06eecb@sudeepholla> <5325A2E7-4987-400A-A1B2-A5C3122D88D1@nvidia.com> <20260514-serious-bumblebee-of-prowess-b6bf2b@sudeepholla> <5AF8DFBF-18EC-4C8A-84A0-F27298DB9BD0@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5AF8DFBF-18EC-4C8A-84A0-F27298DB9BD0@nvidia.com> On Thu, May 14, 2026 at 05:37:38PM +0000, Jamie Nguyen wrote: > > > > On May 14, 2026, at 2:16 AM, Sudeep Holla wrote: > > > > On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote: > >> > >> > >>> On May 13, 2026, at 10:15 AM, Sudeep Holla 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