linux-kernel - Re: [PATCH v2 06/11] remoteproc: Move resource table data structure to its own header

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] [day] [month] [year] [list]

Message-ID: <aKX9kO5eHUp40oRj@linaro.org>
Date: Wed, 20 Aug 2025 18:53:36 +0200
From: Stephan Gerhold <stephan.gerhold@...aro.org>
To: Mukesh Ojha <mukesh.ojha@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konradybcio@...nel.org>,
	Vikash Garodia <quic_vgarodia@...cinc.com>,
	Dikshita Agarwal <quic_dikshita@...cinc.com>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Abhinav Kumar <abhinav.kumar@...ux.dev>,
	Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-media@...r.kernel.org, linux-remoteproc@...r.kernel.org
Subject: Re: [PATCH v2 06/11] remoteproc: Move resource table data structure
 to its own header

On Wed, Aug 20, 2025 at 10:02:50PM +0530, Mukesh Ojha wrote:
> On Wed, Aug 20, 2025 at 08:48:22PM +0530, Mukesh Ojha wrote:
> > On Wed, Aug 20, 2025 at 10:12:15AM +0200, Stephan Gerhold wrote:
> > > On Tue, Aug 19, 2025 at 10:24:41PM +0530, Mukesh Ojha wrote:
> > > > The resource table data structure has traditionally been associated with
> > > > the remoteproc framework, where the resource table is included as a
> > > > section within the remote processor firmware binary. However, it is also
> > > > possible to obtain the resource table through other means—such as from a
> > > > reserved memory region populated by the boot firmware, statically
> > > > maintained driver data, or via a secure SMC call—when it is not embedded
> > > > in the firmware.
> > > > 
> > > > There are multiple Qualcomm remote processors (e.g., Venus, Iris, GPU,
> > > > etc.) in the upstream kernel that do not use the remoteproc framework to
> > > > manage their lifecycle for various reasons.
> > > > 
> > > > When Linux is running at EL2, similar to the Qualcomm PAS driver
> > > > (qcom_q6v5_pas.c), client drivers for subsystems like video and GPU may
> > > > also want to use the resource table SMC call to retrieve and map
> > > > resources before they are used by the remote processor.
> > > > 
> > > 
> > > All the examples you give here (Venus/Iris, GPU) have some sort of EL2
> > > support already for older platforms:
> > 
> > Example was taken from perspective of remote processor life-cycle management.
> > You are right they have worked before in non-secure way for Chrome.
> > 
> > > 
> > >  - For GPU, we just skip loading the ZAP shader and access the protected
> > >    registers directly. I would expect the ZAP shader does effectively
> > >    the same, perhaps with some additional handling for secure mode. Is
> > >    this even a real remote processor that has a separate IOMMU domain?
> > > 
> > 
> > I don't think it is the case and think the same that they can skip
> > loading and Hence, I have not yet added support for it.
> > 
> > Will check internally before doing anything on GPU.
> > 
> > >  - For Venus/Iris, there is code upstream similar to your PATCH 11/11
> > >    that maps the firmware with the IOMMU (but invokes reset directly
> > >    using the registers, without using PAS). There is no resource table
> > >    used for that either, so at least all Venus/Iris versions so far
> > >    apparently had no need for any mappings aside from the firmware
> > >    binary.
> > 
> > You are absolutely right
> > 
> > > 
> > > I understand that you want to continue using PAS for these, but I'm a
> > > bit confused what kind of mappings we would expect to have in the
> > > resource table for video and GPU. Could you give an example?
> > 
> > We have some debug hw tracing available for video for lemans, which is
> > optional However, I believe infra is good to have incase we need some
> > required resources to be map for Video to work for a SoC.
> > 
> > > 
> > > Thanks,
> > > Stephan
> > 
> > -- 
> > -Mukesh Ojha
> 
> Since I am not subscribed to any of the mailing lists to which this
> series was sent, I am not receiving emails from the list. As a result,
> your recent messages did not reach my inbox. Additionally, it seems your
> reply inadvertently removed me from the To-list.
> 
> 
> https://lore.kernel.org/lkml/aKXqSU-487b6Je2B@linaro.org/
> 
> https://lore.kernel.org/lkml/aKXQAoXZyR6SRPAA@linaro.org/
> 

Indeed, but I don't think this is my fault: You have a strange
"Mail-Followup-To:" list in the email header of your reply [1] and my
email client honors it when I press "group reply". Your email client or
server seems to produce this header without including you in the follow
up list, as if you don't want to receive any replies. :-)

I fixed it up manually this time, but perhaps you should look into the
source of this weird header in your replies, I'm probably not the only
person using mutt and just hitting "group reply" all the time ...

Stephan

[1]: https://lore.kernel.org/linux-arm-msm/20250820163250.hszey3i2gtd3o2i6@hu-mojha-hyd.qualcomm.com/raw