On Thu, 25 Jul 2024 at 07:15, Amirreza Zarrabi quic_azarrabi@quicinc.com 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@quicinc.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.

Ack