linux-kernel - Re: [PATCH v2 1/5] dt-bindings: firmware: qcom,scm: Document SDI disable

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]

Date:   Mon, 21 Aug 2023 12:44:41 -0700
From:   Brian Norris <computersforpeace@...il.com>
To:     Robert Marko <robimarko@...il.com>
Cc:     Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        quic_gurus@...cinc.com, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] dt-bindings: firmware: qcom,scm: Document SDI disable

On Mon, Aug 21, 2023 at 12:35 PM Robert Marko <robimarko@...il.com> wrote:
> On Mon, 21 Aug 2023 at 21:31, Rob Herring <robh@...nel.org> wrote:
> > Why can't you just disable SDI unconditionally when going into debug
> > mode? Is doing that when not enabled going to crash the system or
> > something?

I asked the same, to resounding silence:

https://lore.kernel.org/all/20200721080054.2803881-1-computersforpeace@gmail.com/
https://lore.kernel.org/all/ZNlhSdh0qDMieTAS@localhost/

> Because if not disabled you will enter the Secure Debug mode even on a
> regular reboot and then you have to pull the power in order to boot again.
> Even according to QCA docs they intended for the Linux to disable SDI as
> TZ/QSEE will always enable it as part of booting.

NB: I've never read such docs. Presumably they're internal/private to
Qualcomm and/or its direct partners? I'd love to see them.

But, I think you (robinmarko) are not really answering the same
question that Rob (robh) is asking. Rob is asking why you ever *don't*
want to disable SDI. You're answering why we ever need to disable it
at all. I don't think the latter question is controversial.

FWIW, your description of those docs sounds like we should
unconditionally *disable* SDI (like my first RFC above), which would
answer Rob's question, and would agree with my RFC above :) And as a
bonus, no Device Tree change would be required.

Brian