Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support

Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support

[Konrad Dybcio]

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

Re: [PATCH v2 0/9] remoteproc: qcom_q6v5_wcss: add native ipq9574 support

[Alex G.]

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