* Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support [not found] ` <27098742.6Emhk5qWAg@nukework.gtech> @ 2026-04-24 12:17 ` Konrad Dybcio 2026-05-08 2:45 ` Alex G. 0 siblings, 1 reply; 2+ messages in thread From: Konrad Dybcio @ 2026-04-24 12:17 UTC (permalink / raw) To: Alex G., andersson, krzk+dt, mturquette, linux-remoteproc Cc: mathieu.poirier, robh, conor+dt, konradybcio, sboyd, p.zabel, linux-arm-msm, devicetree, linux-kernel, linux-clk On 1/15/26 6:27 AM, Alex G. wrote: > On Wednesday, January 14, 2026 4:26:36 AM CST Konrad Dybcio wrote: >> On 1/14/26 4:54 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. >> >> I wouldn't exactly call it an afterthought.. Image authentication (as in, >> verifying the signature of the ELF) has always been part of TZ, because >> doing so in a user-modifiable context would be absolutely nonsensical >> >> qcom_scm_pas_auth_and_reset() which configures and powers up the rproc >> has been there for a really long time too (at least since the 2012 SoCs >> like MSM8974) and I would guesstimate it's been there for a reason - not >> all clocks can or should be accessible from the OS (from a SW standpoint >> it would be convenient to have a separate SECURE_CC block where all the >> clocks we shouldn't care about are moved, but the HW design makes more >> sense as-is, for the most part), plus there is additional access control >> hardware on the platform that must be configured from a secure context >> (by design) which I assume could be part of this sequence, based on >> the specifics of a given SoC > > What was the original use case for the Q6 remoteproc? I see today's use case > is as a conduit for ath11k firmware to control PCIe devices. Was that always > the case? I imagine a more modern design would treat the remoteproc as > untrusted by putting it under a bridge or IOMMU with more strict memory access > control, so that firmware couldn't access OS memory. There is an SMMU on this SoC. I don't know the original backstory, but if anything, the through-Q6 approach is probably *more* secure, since there's additional access control hardware inbetween Konrad ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support 2026-04-24 12:17 ` [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support Konrad Dybcio @ 2026-05-08 2:45 ` Alex G. 0 siblings, 0 replies; 2+ messages in thread From: Alex G. @ 2026-05-08 2:45 UTC (permalink / raw) To: andersson, krzk+dt, mturquette, linux-remoteproc, Konrad Dybcio Cc: mathieu.poirier, robh, conor+dt, konradybcio, sboyd, p.zabel, linux-arm-msm, devicetree, linux-kernel, linux-clk On Friday, April 24, 2026 7:17:05 AM Central Daylight Time Konrad Dybcio wrote: > On 1/15/26 6:27 AM, Alex G. wrote: > > On Wednesday, January 14, 2026 4:26:36 AM CST Konrad Dybcio wrote: > >> On 1/14/26 4:54 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. > >> > >> I wouldn't exactly call it an afterthought.. Image authentication (as in, > >> verifying the signature of the ELF) has always been part of TZ, because > >> doing so in a user-modifiable context would be absolutely nonsensical > >> > >> qcom_scm_pas_auth_and_reset() which configures and powers up the rproc > >> has been there for a really long time too (at least since the 2012 SoCs > >> like MSM8974) and I would guesstimate it's been there for a reason - not > >> all clocks can or should be accessible from the OS (from a SW standpoint > >> it would be convenient to have a separate SECURE_CC block where all the > >> clocks we shouldn't care about are moved, but the HW design makes more > >> sense as-is, for the most part), plus there is additional access control > >> hardware on the platform that must be configured from a secure context > >> (by design) which I assume could be part of this sequence, based on > >> the specifics of a given SoC > > > > What was the original use case for the Q6 remoteproc? I see today's use > > case is as a conduit for ath11k firmware to control PCIe devices. Was > > that always the case? I imagine a more modern design would treat the > > remoteproc as untrusted by putting it under a bridge or IOMMU with more > > strict memory access control, so that firmware couldn't access OS memory. > > There is an SMMU on this SoC. > > I don't know the original backstory, but if anything, the through-Q6 > approach is probably *more* secure, since there's additional access > control hardware inbetween My question is what to do with this series? I think I present a valid approach which has its use cases, irrespective of which approach is better for a given use case. Alex > Konrad ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-05-08 2:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260109043352.3072933-1-mr.nuke.me@gmail.com>
[not found] ` <4814455.tdWV9SEqCh@nukework.gtech>
[not found] ` <577d547e-6311-49b3-9c74-84797b281447@oss.qualcomm.com>
[not found] ` <27098742.6Emhk5qWAg@nukework.gtech>
2026-04-24 12:17 ` [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support Konrad Dybcio
2026-05-08 2:45 ` Alex G.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox