linux-kernel - Re: [PATCH v3 2/4] firmware: Add support for Qualcomm Secure Execution Environment SCM 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57dd6b7f-6f30-9fc5-0cbc-7d28a2f65f6a@gmail.com>
Date:   Thu, 9 Mar 2023 21:54:32 +0100
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        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>,
        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
Subject: Re: [PATCH v3 2/4] firmware: Add support for Qualcomm Secure
 Execution Environment SCM interface

On 3/9/23 09:45, Dmitry Baryshkov wrote:
> On 08/03/2023 15:59, Maximilian Luz wrote:
>> On 3/7/23 16:32, Dmitry Baryshkov wrote:
>>> On 05/03/2023 04:21, Maximilian Luz wrote:

[...]

>>>> +int qseecom_scm_call(struct qseecom_device *qsee, const struct qcom_scm_desc *desc,
>>>> +             struct qseecom_scm_resp *res);
>>>> +
>>>> +
>>>> +/* -- Secure App interface. ------------------------------------------------- */
>>>> +
>>>> +#define QSEECOM_MAX_APP_NAME_SIZE            64
>>>> +
>>>> +int qseecom_app_get_id(struct qseecom_device *qsee, const char *app_name, u32 *app_id);
>>>> +int qseecom_app_send(struct qseecom_device *qsee, u32 app_id, struct qseecom_dma *req,
>>>> +             struct qseecom_dma *rsp);
>>>
>>> I think that only these calls should be made public / available to other modules. qseecom_scm_call also is an internal helper.
>>
>> So move all calls to qcom_scm and only make these two public? Or move only
>> qseecom_scm_call() to qcom_scm (which would require to make it public there,
>> however). Or how would you want this to look?
> 
> I think we can make it with just these calls being public. Or even with just the second one being public and available to other drivers. If the app_id is a part of qseecom_app_device, we can pass that device to the qseecom_app_send(). And qseecom_app_get_id() becomes a part of app registration.

Right, with the bus structure, we only really need qseecom_app_send().

I'm still a bit concerned about things maybe getting too complex for
qcom_scm with the blocking/re-entrant calls (and maybe other future
stuff), but I guess we can always try to break things up when/if we get
around to that.

I'll try to implement that and your other suggestions and see how that
goes. I think that should work quite well overall.

Thanks again for your review and comments.

Regards,
Max