linux-kernel - Re: [PATCH v3 1/4] firmware: qcom

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 12:53:42 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Maximilian Luz <luzmaximilian@...il.com>,
        Bjorn Andersson <andersson@...nel.org>
Cc:     Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Rob Herring <robh+dt@...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>,
        Sumit Garg <sumit.garg@...aro.org>,
        Steev Klimaszewski <steev@...i.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/4] firmware: qcom_scm: Export SCM call functions



On 07/03/2023 15:23, Dmitry Baryshkov wrote:
> 
>> Make qcom_scm_call, qcom_scm_call_atomic and associated types accessible
>> to other modules.
> 
> Generally all the qcom_scm calls are a part of qcom_scm.c. I think it is 
> better to make qseecom_scm_call a part qcom_scm.c (as we were previously 
> doing) rather than exporting the core function.
>

Other big issue I see in exporting qcom_scm_call() is that there is 
danger of misuse of this api as this could lead to a path where new apis 
and its payloads can come directly from userspace via a rogue/hacking 
modules. This will bypass scm layer completely within kernel.

--srini

> If you wish to limit the kernel bloat, you can split the qcom_scm into 
> per-driver backend and add Kconfig symbols to limit the impact. However 
> I think that these functions are pretty small to justify the effort.
> 


>>
>> Signed-off-by: Maximilian Luz <luzmaximilian@...il.com>