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.

Sign up for GitHub

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

Jump to bottom

HiKey: xtest 7505 and 7633 (GP) fail with RPMB #1332

Closed
jforissier opened this issue Feb 1, 2017 · 0 comments · Fixed by #1334
Closed

HiKey: xtest 7505 and 7633 (GP) fail with RPMB #1332

jforissier opened this issue Feb 1, 2017 · 0 comments · Fixed by #1334

Comments

@jforissier
Copy link
Contributor

I'm running xtest with GP tests and with RPMB as the only file system for secure storage, i.e., CFG_REE_FS=n CFG_SQL_FS=n CFG_RPMB_FS=y CFG_RPMB_WRITE_KEY=y.
Two GP tests fail:

root@HiKey:/ xtest 7505 7633
Test ID: 7505
Test ID: 7633
Run test suite with level=0

TEE test application started with device [(null)]
######################################################
#
# regression
#
######################################################
 
* regression_7505 9d-52-ec
./xml/include/xml_datastorage_api.h:971: Expression "op.params[0].value.a == 0" (4294967295 == 0) is false
  regression_7505 FAILED
 
* regression_7633 9d-a5-74
ERROR:   USER-TA: Panic 0xffff0006
ERROR:   TEE-CORE: TA panicked with code 0xffff0006 usr_sp 0x40000b90 usr_lr 0x223fca8140007147
/home/jerome/work/hikey_optee/optee_test/host/xtest/xtest_7500.c:2011: Invoke_EnumeratorOnPersistentObjects(c, SESSION01, 0x00001016) has an unexpected value: 0xffff3024, expected 0x0
  regression_7633 FAILED
+-----------------------------------------------------
Result of testsuite regression filtered by "7505":
Result of testsuite regression filtered by "7633":
regression_7505 FAILED first error at ./xml/include/xml_datastorage_api.h:971
regression_7633 FAILED first error at /home/jerome/work/hikey_optee/optee_test/host/xtest/xtest_7500.c:2011
+-----------------------------------------------------
20 subtests of which 2 failed
2 test cases of which 2 failed
700 test cases was skipped
TEE test application done!

All other tests cases are successful.
jforissier added a commit to jforissier/optee_os that referenced this issue Feb 2, 2017
@jforissier
core: RPMB FS: nullify fops when resetting an enumerator
813ed43 
According to the GP spec, TEE_ResetPersistentObjectEnumerator() "resets
an object enumerator handle to its initial state after allocation".
Therefore, syscall_storage_reset_enum() should set e->fops = NULL.

This fixes a regression introduced when the FOP interface was reworked.
I'm not simply reverting the return code from TEE_ERROR_GENERIC back to
TEE_ERROR_ITEM_NOT_FOUND, because the new code makes sense and it is
more sane to properly reset the state of the enumerator.

Consequently, tee_svc_close_enum() is updated to accept e->fops == NULL
which is valid when the enum has just been allocated or reset but not
started. We should not return an error status in this case.

Tested on HiKey using xtest with GP tests (all 3 filesystems: REE, SQL,
RPMB).

Fixes: b86c18e ("core: RPMB FS: prepare for new FOP interface")
Fixes: OP-TEE#1332
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
@jforissier jforissier mentioned this issue Feb 2, 2017
Merged
jforissier added a commit to jforissier/optee_os that referenced this issue Feb 3, 2017
@jforissier
core: RPMB FS: nullify fops when resetting an enumerator
928468c 
According to the GP spec, TEE_ResetPersistentObjectEnumerator() "resets
an object enumerator handle to its initial state after allocation".
Therefore, syscall_storage_reset_enum() should set e->fops = NULL.

This fixes a regression introduced when the FOP interface was reworked.
I'm not simply reverting the return code from TEE_ERROR_GENERIC back to
TEE_ERROR_ITEM_NOT_FOUND, because the new code makes sense and it is
more sane to properly reset the state of the enumerator.

Consequently, tee_svc_close_enum() is updated to accept e->fops == NULL
which is valid when the enum has just been allocated or reset but not
started. We should not return an error status in this case.

Tested on HiKey using xtest with GP tests (all 3 filesystems: REE, SQL,
RPMB).

Fixes: b86c18e ("core: RPMB FS: prepare for new FOP interface")
Fixes: OP-TEE#1332
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
takuya-sakata pushed a commit to renesas-rcar/optee_os that referenced this issue Dec 22, 2017
@jforissier @takuya-sakata
core: RPMB FS: nullify fops when resetting an enumerator
2891b69 
According to the GP spec, TEE_ResetPersistentObjectEnumerator() "resets
an object enumerator handle to its initial state after allocation".
Therefore, syscall_storage_reset_enum() should set e->fops = NULL.

This fixes a regression introduced when the FOP interface was reworked.
I'm not simply reverting the return code from TEE_ERROR_GENERIC back to
TEE_ERROR_ITEM_NOT_FOUND, because the new code makes sense and it is
more sane to properly reset the state of the enumerator.

Consequently, tee_svc_close_enum() is updated to accept e->fops == NULL
which is valid when the enum has just been allocated or reset but not
started. We should not return an error status in this case.

Tested on HiKey using xtest with GP tests (all 3 filesystems: REE, SQL,
RPMB).

Fixes: b86c18e ("core: RPMB FS: prepare for new FOP interface")
Fixes: OP-TEE/optee_os#1332
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

core: RPMB FS: nullify fops when resetting an enumerator jforissier/optee_os
1 participant
@jforissier