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

core: RPMB FS: nullify fops when resetting an enumerator #1334

Merged
merged 1 commit into from
Feb 3, 2017

Conversation

jforissier
Copy link
Contributor

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: #1332
Signed-off-by: Jerome Forissier [email protected]

@jenswi-linaro
Copy link
Contributor

Reviewed-by: Jens Wiklander <[email protected]>

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 <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
@jforissier jforissier merged commit 928468c into OP-TEE:master Feb 3, 2017
@jforissier jforissier deleted the enum-fix branch February 3, 2017 08:39
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 this pull request may close these issues.

HiKey: xtest 7505 and 7633 (GP) fail with RPMB
2 participants