linux-kernel - Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support

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]

Message-ID: <a1f4457a-2313-4d75-9857-0d82cd502343@quicinc.com>
Date: Thu, 25 Jul 2024 14:15:25 +1000
From: Amirreza Zarrabi <quic_azarrabi@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio
	<konrad.dybcio@...aro.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Christian König <christian.koenig@....com>,
        <srinivas.kandagatla@...aro.org>, <bartosz.golaszewski@...aro.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <dri-devel@...ts.freedesktop.org>, <linaro-mm-sig@...ts.linaro.org>
Subject: Re: [PATCH RFC 1/3] firmware: qcom: implement object invoke support



On 7/25/2024 2:09 PM, Dmitry Baryshkov wrote:
> On Thu, Jul 25, 2024 at 01:19:07PM GMT, Amirreza Zarrabi wrote:
>>
>>
>> On 7/4/2024 5:34 PM, Dmitry Baryshkov wrote:
>>> On Thu, 4 Jul 2024 at 00:40, Amirreza Zarrabi <quic_azarrabi@...cinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/3/2024 10:13 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, Jul 02, 2024 at 10:57:36PM GMT, Amirreza Zarrabi wrote:
>>>>>> Qualcomm TEE hosts Trusted Applications and Services that run in the
>>>>>> secure world. Access to these resources is provided using object
>>>>>> capabilities. A TEE client with access to the capability can invoke
>>>>>> the object and request a service. Similarly, TEE can request a service
>>>>>> from nonsecure world with object capabilities that are exported to secure
>>>>>> world.
>>>>>>
>>>>>> We provide qcom_tee_object which represents an object in both secure
>>>>>> and nonsecure world. TEE clients can invoke an instance of qcom_tee_object
>>>>>> to access TEE. TEE can issue a callback request to nonsecure world
>>>>>> by invoking an instance of qcom_tee_object in nonsecure world.
>>>>>
>>>>> Please see Documentation/process/submitting-patches.rst on how to write
>>>>> commit messages.
>>>>
>>>> Ack.
>>>>
>>>>>
>>>>>>
>>>>>> Any driver in nonsecure world that is interested to export a struct (or a
>>>>>> service object) to TEE, requires to embed an instance of qcom_tee_object in
>>>>>> the relevant struct and implements the dispatcher function which is called
>>>>>> when TEE invoked the service object.
>>>>>>
>>>>>> We also provids simplified API which implements the Qualcomm TEE transport
>>>>>> protocol. The implementation is independent from any services that may
>>>>>> reside in nonsecure world.
>>>>>
>>>>> "also" usually means that it should go to a separate commit.
>>>>
>>>> I will split this patch to multiple smaller ones.
>>>>
>>>
>>> [...]
>>>
>>>>>
>>>>>> +    } in, out;
>>>>>> +};
>>>>>> +
>>>>>> +int qcom_tee_object_do_invoke(struct qcom_tee_object_invoke_ctx *oic,
>>>>>> +    struct qcom_tee_object *object, unsigned long op, struct qcom_tee_arg u[], int *result);
>>>>>
>>>>> What's the difference between a result that gets returned by the
>>>>> function and the result that gets retuned via the pointer?
>>>>
>>>> The function result, is local to kernel, for instance memory allocation failure,
>>>> or failure to issue the smc call. The result in pointer, is the remote result,
>>>> for instance return value from TA, or the TEE itself.
>>>>
>>>> I'll use better name, e.g. 'remote_result'?
>>>
>>> See how this is handled by other parties. For example, PSCI. If you
>>> have a standard set of return codes, translate them to -ESOMETHING in
>>> your framework and let everybody else see only the standard errors.
>>>
>>>
>>
>> I can not hide this return value, they are TA dependent. The client to a TA
>> needs to see it, just knowing that something has failed is not enough in
>> case they need to do something based on that. I can not even translate them
>> as they are TA related so the range is unknown.
> 
> I'd say it a sad design. At least error values should be standard.
> 

Sure. But it is normal. If we finally move to TEE subsystem, this is the value that
would be copied to struct tee_ioctl_invoke_arg.ret to pass to the caller of
TEE_IOC_INVOKE.