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 Konrad
