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: <577d547e-6311-49b3-9c74-84797b281447@oss.qualcomm.com>
Date: Wed, 14 Jan 2026 11:26:36 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: "Alex G." <mr.nuke.me@...il.com>, andersson@...nel.org, krzk+dt@...nel.org,
        mturquette@...libre.com, linux-remoteproc@...r.kernel.org
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 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