linux-kernel - Re: [PATCH v3 3/4] dt-bindings: firmware: Add Qualcomm QSEECOM interface

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:   Wed, 8 Mar 2023 23:44:07 +0100
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Bjorn Andersson <andersson@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Johan Hovold <johan@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Sumit Garg <sumit.garg@...aro.org>,
        Steev Klimaszewski <steev@...i.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 3/4] dt-bindings: firmware: Add Qualcomm QSEECOM
 interface

On 3/8/23 23:16, Rob Herring wrote:
> On Sun, Mar 05, 2023 at 03:21:18AM +0100, Maximilian Luz wrote:
>> Add bindings for the Qualcomm Secure Execution Environment interface
>> (QSEECOM).
> 
> Pretty sure I already asked, but no answer in the commit message. Why do
> we need this? You've already declared the platform supports SCM calls
> with "qcom,scm". Why can't you probe whether you have QSEECOM or not? DT
> is for non-discoverable h/w we are stuck with.

Yes, you've asked this before but I can only repeat what I've written in
my last response to your question: I am not aware of any way to properly
discover the interface at runtime from software.

If it makes you happy, I can put this in the commit message as well...

> Why is software made non-discoverable too?

Please direct that question at the Qualcomm guys who actually designed
that interface. I can't give you an answer to that, and I'm not all that
happy about this either.

To reiterate: I've reverse engineered this based on the Windows driver.
The Windows driver loads on an ACPI HID and it doesn't use any function
to check/verify whether the interface is actually present. Adding a DT
entry is the straight-forward adaption to having a HID in ACPI.

> Nodes with only a compatible string are usually just an abuse of DT to
> instantiate some driver.

If you or anyone here has any idea on how to discover the presence of
this, please feel free to let me know and I'd be happy to implement
that. Until then, I unfortunately don't see any other way of dealing
with this.

Regards,
Max