-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Modify obj usage for persistence object #6495
Comments
That's not expected. While looking at the code optee_os/core/tee/tee_svc_cryp.c Lines 1197 to 1212 in c7f9abc
I can't find anything obvious. We don't have a test case for this in xtest. Could you create such a test case? With a test case to demonstrate the problem, it is much easier to fix it, besides a test case would guarantee that this remains working after an eventual fix has been merged. |
I see how this might fail now. Yeah, this is a bug. |
Hi jenswi-linaro,
Thanks for your help |
Before this patch was the object usage field stored in the non-persistent part of an object handle, regardless of whether the storage object was persistent. This prevents updates to this field from being restored the next time the persistent object is opened. Updates to the field are also not replicated to eventual other open handles for the object. Fix this by storing the "usage" bits in a new obj_info_usage field in struct tee_pobj for persistent objects. Updates to the field are also written into secure storage to preserve the content the next time the object is opened. Fixes: b010477 ("Open-source the TEE Core") Closes: OP-TEE#6495 Signed-off-by: Jens Wiklander <[email protected]>
Adds case 6021 to test modifying and checking object usage of a persistent object. Link: OP-TEE/optee_os#6495 Signed-off-by: Jens Wiklander <[email protected]>
Fixed in #6505 I can add a The test is added in OP-TEE/optee_test#715 Feel free to provide your |
Before this patch was the object usage field stored in the non-persistent part of an object handle, regardless of whether the storage object was persistent. This prevents updates to this field from being restored the next time the persistent object is opened. Updates to the field are also not replicated to eventual other open handles for the object. Fix this by storing the "usage" bits in a new obj_info_usage field in struct tee_pobj for persistent objects. Updates to the field are also written into secure storage to preserve the content the next time the object is opened. Fixes: b010477 ("Open-source the TEE Core") Closes: OP-TEE#6495 Signed-off-by: Jens Wiklander <[email protected]>
Before this patch was the object usage field stored in the non-persistent part of an object handle, regardless of whether the storage object was persistent. This prevents updates to this field from being restored the next time the persistent object is opened. Updates to the field are also not replicated to eventual other open handles for the object. Fix this by storing the "usage" bits in a new obj_info_usage field in struct tee_pobj for persistent objects. Updates to the field are also written into secure storage to preserve the content the next time the object is opened. Fixes: b010477 ("Open-source the TEE Core") Closes: OP-TEE#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
Adds case 6021 to test modifying and checking object usage of a persistent object. Link: OP-TEE/optee_os#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
Add case 6021 to test modifying and checking object usage of a persistent object. Link: OP-TEE/optee_os#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
Before this patch was the object usage field stored in the non-persistent part of an object handle, regardless of whether the storage object was persistent. This prevents updates to this field from being restored the next time the persistent object is opened. Updates to the field are also not replicated to eventual other open handles for the object. Fix this by storing the "usage" bits in a new obj_info_usage field in struct tee_pobj for persistent objects. Updates to the field are also written into secure storage to preserve the content the next time the object is opened. Fixes: b010477 ("Open-source the TEE Core") Closes: OP-TEE#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> Acked-by: Etienne Carriere <[email protected]>
It's ok. |
Before this patch was the object usage field stored in the non-persistent part of an object handle, regardless of whether the storage object was persistent. This prevents updates to this field from being restored the next time the persistent object is opened. Updates to the field are also not replicated to eventual other open handles for the object. Fix this by storing the "usage" bits in a new obj_info_usage field in struct tee_pobj for persistent objects. Updates to the field are also written into secure storage to preserve the content the next time the object is opened. Fixes: b010477 ("Open-source the TEE Core") Closes: #6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> Acked-by: Etienne Carriere <[email protected]>
Add case 6021 to test modifying and checking object usage of a persistent object. Link: OP-TEE/optee_os#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
Add case 6021 to test modifying and checking object usage of a persistent object. Link: OP-TEE/optee_os#6495 Signed-off-by: Jens Wiklander <[email protected]> Reviewed-by: Jerome Forissier <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
optee-4.0.0
Case: Create a pure data object that can not share to CA
But when using the TEE_GetObjectInfo1 API to get object usage from another CA, it will return 0xffffffff.
Is this the expected result?
Thanks
The text was updated successfully, but these errors were encountered: