linux-kernel - Re: [PATCH 1/2] arm64: dts: qcom: sm8250: Disable Adreno and Venus by default

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

Date:   Sat, 12 Jun 2021 21:39:23 +0200
From:   Konrad Dybcio <konrad.dybcio@...ainline.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     ~postmarketos/upstreaming@...ts.sr.ht,
        Martin Botka <martin.botka@...ainline.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        jamipkettunen@...ainline.org, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sm8250: Disable Adreno and Venus by
 default


On 11.06.2021 20:54, Rob Clark wrote:
> On Fri, Jun 11, 2021 at 4:35 AM Konrad Dybcio
> <konrad.dybcio@...ainline.org> wrote:
>> Components that rely on proprietary (not to mention signed!) firmware should
>> not be enabled by default, as lack of the aforementioned firmware could cause
>> various issues, from random errors to straight-up failing to boot.
> I admit I probably don't test much without fw, but I think maybe
> *that* is the issue to solve instead.
>
> Taking a guess, I think the situation is that you have *some* of the
> fw (ie. the unsigned parts coming from linux-firmware) but not
> specifically the zap fw.  So adreno_zap_shader_load() returns -ENODEV,
> which is interpreted to mean "this is a platform that doesn't need zap
> to take GPU out of secure mode", and then things go boom when we try
> to write RBBM_SECVID_TRUST_CNTL ?

While we're not yet there to test that out on A6xx-equipped platforms,

my experience with lack ofAdreno firmware so far has been like so:


no ZAP, wrong ZAP address in the DT, bad ZAP - either a lockup or a reboot


no pm4/pfp - mostly a sane failing route with GPU just not activating after all,

yet still I can recall having some problems that I probably won't be able to

reproduce right now


no GMU fw - as stated before, can't really test properly just yet



Konrad