Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not able to Open Persistent Object #232

Closed
sahilnxp opened this issue Oct 26, 2017 · 6 comments · Fixed by OP-TEE/optee_os#1903
Closed

Not able to Open Persistent Object #232

sahilnxp opened this issue Oct 26, 2017 · 6 comments · Fixed by OP-TEE/optee_os#1903

Comments

@sahilnxp
Copy link
Contributor

Hi All,

I am new to TA programming and having some issue with the Persistent Objects creation/opening.
Below is the code snippet and output when i run the code.
In this program first created a Persistent Object then Opened it and then Closed it.
After this I tried creating already created Persistent Object, It gives the TEE_ERROR_ACCESS_CONFLICT, which i fine.

After this when I tried opening that Persistent Object it is again giving the TEE_ERROR_ACCESS_CONFLICT, which I am not able to understand.

I want to know that why Second TEE_OpenPersistentObject is failing ?
Is there any limitation that if you try creating an already created PersistentObject, access to that object is locked somehow ?

Any help on this is really appreciated.

image

image

Thanks
Sahil

@jbech-linaro
Copy link
Contributor

Hi @sahilnxp ,

Please have a look at the not yet merged pull request here so see whether that helps understand how to work with persistent storage objects.
linaro-swg/optee_examples#5

// Joakim

@sahilnxp
Copy link
Contributor Author

Hi @jbech-linaro

Thanks for reply.
I studied the code given in the pull request, but it is not having the case I am trying.

I am trying to create an already created Persistent object without TEE_DATA_FLAG_OVERWRITE which is giving me the TEEC_ERROR_ACCESS_CONFLICT, which is correct according to the specification.
After getting this error since I know that the object is already created, so I tried opening that Persistent Object but it is giving the TEEC_ERROR_ACCESS_CONFLICT.

So I want to understand that if we try creating an already created object without TEE_DATA_FLAG_OVERWRITE, then we will be not be able to open that object any further ?

Thanks,
Sahil

etienne-lms added a commit to etienne-lms/optee_os that referenced this issue Oct 27, 2017
Changes syscall_storage_obj_create to give physical object ownership
to the tee object layer only once storage is successfully inited
for that object. Otherwise, if tee_svc_storage_init_file fails,
the storage does not own the physical object and close method
will not release the object.

This change fixes OP-TEE/optee_test#232.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
@etienne-lms
Copy link
Contributor

This puzzle me and i tried to same from the ote_secure_storage. I think you spotted an issue in the core. The create_object without overwrite fails, but it still create an object instance and does not release it. See OP-TEE/optee_os#1903 (needs storage experts review).

@sahilnxp
Copy link
Contributor Author

Thanks @etienne-lms for the fix.

When I was going through pull request linaro-swg/optee_examples#5, I think i found a typo in error message at 204 line of secure_storage/host/main.c file.
If I understood correctly, it should be "Failed to read object from secure storage" instead of "Failed to create an object in the secure storage".

@etienne-lms
Copy link
Contributor

Thank you @sahilnxp. Could you add the comment straight in linaro-swg/optee_examples#5? It will be more handy to track and fix.

etienne-lms added a commit to etienne-lms/optee_os that referenced this issue Oct 27, 2017
Changes syscall_storage_obj_create to give physical object ownership
to the tee object layer only once storage is successfully inited
for that object. Otherwise, if tee_svc_storage_init_file fails,
the storage does not own the physical object and close method
will not release the object.

This change fixes OP-TEE/optee_test#232.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
@sahilnxp
Copy link
Contributor Author

@etienne-lms , added the comment in pull request.

Thanks
Sahil

jforissier pushed a commit to OP-TEE/optee_os that referenced this issue Nov 2, 2017
Changes syscall_storage_obj_create to give physical object ownership
to the tee object layer only once storage is successfully inited
for that object. Otherwise, if tee_svc_storage_init_file fails,
the storage does not own the physical object and close method
will not release the object.

This change fixes OP-TEE/optee_test#232.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
takuya-sakata pushed a commit to renesas-rcar/optee_os that referenced this issue May 28, 2018
Changes syscall_storage_obj_create to give physical object ownership
to the tee object layer only once storage is successfully inited
for that object. Otherwise, if tee_svc_storage_init_file fails,
the storage does not own the physical object and close method
will not release the object.

This change fixes OP-TEE/optee_test#232.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
jordanrh1 pushed a commit to ms-iot/optee_os that referenced this issue Oct 16, 2018
Changes syscall_storage_obj_create to give physical object ownership
to the tee object layer only once storage is successfully inited
for that object. Otherwise, if tee_svc_storage_init_file fails,
the storage does not own the physical object and close method
will not release the object.

This change fixes OP-TEE/optee_test#232.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants