linux-kernel - Re: [PATCH v2 0/9] remoteproc: qcom_q6v5

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

Message-ID: <5206383.iZASKD2KPV@nukework.gtech>
Date: Wed, 14 Jan 2026 22:50:40 -0600
From: "Alex G." <mr.nuke.me@...il.com>
To: andersson@...nel.org, krzk+dt@...nel.org, mturquette@...libre.com,
 linux-remoteproc@...r.kernel.org,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Vignesh Viswanathan <vignesh.viswanathan@....qualcomm.com>
Cc: mathieu.poirier@...aro.org, robh@...nel.org, conor+dt@...nel.org,
 konradybcio@...nel.org, sboyd@...nel.org, p.zabel@...gutronix.de,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject:
 Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support

On Tuesday, January 13, 2026 11:42:45 PM CST Vignesh Viswanathan wrote:
> On 1/14/2026 9:24 AM, Alex G. wrote:
> > On Tuesday, January 13, 2026 8:28:11 AM CST Konrad Dybcio wrote:
> >> On 1/9/26 5:33 AM, Alexandru Gagniuc wrote:
> >>> Support loading remoteproc firmware on IPQ9574 with the qcom_q6v5_wcss
> >>> driver. This firmware is usually used to run ath11k firmware and enable
> >>> wifi with chips such as QCN5024.
> >>> 
> >>> When submitting v1, I learned that the firmware can also be loaded by
> >>> the trustzone firmware. Since TZ is not shipped with the kernel, it
> >>> makes sense to have the option of a native init sequence, as not all
> >>> devices come with the latest TZ firmware.
> >>> 
> >>> Qualcomm tries to assure us that the TZ firmware will always do the
> >>> right thing (TM), but I am not fully convinced
> >> 
> >> Why else do you think it's there in the firmware? :(
> > 
> > A more relevant question is, why do some contributors sincerely believe
> > that the TZ initialization of Q6 firmware is not a good idea for their
> > use case?
> > 
> > To answer your question, I think the TZ initialization is an afterthought
> > of the SoC design. I think it was only after ther the design stage that
> > it was brought up that a remoteproc on AHB has out-of-band access to
> > system memory, which poses security concerns to some customers. I think
> > authentication was implemented in TZ to address that. I also think that
> > in order to prevent clock glitching from bypassing such verification,
> > they had to move the initialization sequence in TZ as well.
> 
> Exactly, the TZ interface is present to address the security concerns.
> Also, as I mentioned in [1], on some platforms, TZ might access protect the
> clocks and registers which might prevent the remoteproc bringup and throw
> an access violation.
> 
> We can keep this support added for IPQ9574, as it is good to have, but can
> we keep the default compatible in ipq9574 DTSI to use the TZ interface,
> which has already picked up an R-b in this series [2].

I think that's an acceptable plan. For the TZ case, we'd have to keep the 
clock framework from disabling the "unused" remoteproc clocks. Do you think 
"protected-clocks" property is the right way to do it? Which series should add 
it?

Alex

> 
> [1]
> https://lore.kernel.org/linux-remoteproc/21468f66-56df-43ea-99c2-7257d8d6bb
> 7c@....qualcomm.com/T/#m688033ab79c63a8953e38f5575d1c0ff6b37b13a [2]
> https://lore.kernel.org/linux-remoteproc/20260113092021.1887980-1-varadaraj
> an.narayanan@....qualcomm.com/T/#t
> > Alex