On Thu, 25 Jul 2024 at 07:15, Amirreza Zarrabi <quic_azarrabi@xxxxxxxxxxx> wrote: > > > > 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@xxxxxxxxxxx> 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. Ack -- With best wishes Dmitry
