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 22:39:37 +0200
From:   Robert Marko <robimarko@...il.com>
To:     Brian Norris <computersforpeace@...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, 21 Aug 2023 at 21:44, Brian Norris <computersforpeace@...il.com> wrote:
>
> 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.

Sadly they are all behind the NDA.

>
> 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.

I understood his question differently, hence my answer.

>
> 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.

Well, the thing is that I only have docs for some of the IPQ chips, and with
the insane variety of SoC-s that use SCM and TZ/QSEE but completely
different FW base or version something would break for sure so I would
prefer to opt-in if its really required as SDI was something that was until
IPQ5018 came along, always disabled by default, except for the weird
Google WiFI board.

Regards,
Robert
>
> Brian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ