| Message ID | 1543927039-5504-1-git-send-email-igor.opaniuk@linaro.org |
|---|---|
| State | Accepted |
| Commit | 8b1312662b3b1748c3d5f8a30bc6f9ca72879c7a |
| Headers | show |
| Series | [1/1] tee: change return code for REE FS supplicant cmd | expand |
On Tue, Dec 4, 2018 at 1:37 PM Igor Opaniuk <igor.opaniuk@linaro.org> wrote: > > If OP-TEE core is compiled with support of REE FS and RPMB > at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent > storage API is used with TEE_STORAGE_PRIVATE storage id, it will > lead to TA panic. > > E/TC:? 0 TA panicked with code 0xffff0009 > ..... > E/TC:? 0 Call stack: > E/TC:? 0 0x000000004002f2f8 TEE_OpenPersistentObject at > lib/libutee/tee_api_objects.c:422 > > In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable > than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility > to handle this error code [1]. > > From GPD TEE Internal Core specification [2]: > TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a > storage area which is currently inaccessible. It may be associated with > the device but unplugged, busy, or inaccessible for some other reason. > > [1]: https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419 > [2]: https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf > > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> > --- > drivers/tee/optee/supplicant.c | 4 ++-- > include/tee.h | 1 + > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c > index b1ea65b..c5726ec 100644 > --- a/drivers/tee/optee/supplicant.c > +++ b/drivers/tee/optee/supplicant.c > @@ -82,8 +82,8 @@ void optee_suppl_cmd(struct udevice *dev, struct tee_shm *shm_arg, > cmd_shm_free(arg); > break; > case OPTEE_MSG_RPC_CMD_FS: > - debug("OPTEE_MSG_RPC_CMD_FS not implemented\n"); > - arg->ret = TEE_ERROR_NOT_IMPLEMENTED; > + debug("REE FS storage isn't available\n"); > + arg->ret = TEE_ERROR_STORAGE_NOT_AVAILABLE; > break; > case OPTEE_MSG_RPC_CMD_RPMB: > optee_suppl_cmd_rpmb(dev, arg); > diff --git a/include/tee.h b/include/tee.h > index 98b1c9c..edd9f9b 100644 > --- a/include/tee.h > +++ b/include/tee.h > @@ -34,6 +34,7 @@ > * struct tee_version_data::gen_caps > */ > #define TEE_SUCCESS 0x00000000 > +#define TEE_ERROR_STORAGE_NOT_AVAILABLE 0xf0100003 > #define TEE_ERROR_GENERIC 0xffff0000 > #define TEE_ERROR_BAD_PARAMETERS 0xffff0006 > #define TEE_ERROR_ITEM_NOT_FOUND 0xffff0008 > -- > 2.7.4 > Looks good to me: Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Thanks, Jens
On Tue, Dec 04, 2018 at 02:37:19PM +0200, Igor Opaniuk wrote: > If OP-TEE core is compiled with support of REE FS and RPMB > at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent > storage API is used with TEE_STORAGE_PRIVATE storage id, it will > lead to TA panic. > > E/TC:? 0 TA panicked with code 0xffff0009 > ..... > E/TC:? 0 Call stack: > E/TC:? 0 0x000000004002f2f8 TEE_OpenPersistentObject at > lib/libutee/tee_api_objects.c:422 > > In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable > than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility > to handle this error code [1]. > > >From GPD TEE Internal Core specification [2]: > TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a > storage area which is currently inaccessible. It may be associated with > the device but unplugged, busy, or inaccessible for some other reason. > > [1]: https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419 > [2]: https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf > > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> > Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Applied to u-boot/master, thanks! -- Tom
diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c index b1ea65b..c5726ec 100644 --- a/drivers/tee/optee/supplicant.c +++ b/drivers/tee/optee/supplicant.c @@ -82,8 +82,8 @@ void optee_suppl_cmd(struct udevice *dev, struct tee_shm *shm_arg, cmd_shm_free(arg); break; case OPTEE_MSG_RPC_CMD_FS: - debug("OPTEE_MSG_RPC_CMD_FS not implemented\n"); - arg->ret = TEE_ERROR_NOT_IMPLEMENTED; + debug("REE FS storage isn't available\n"); + arg->ret = TEE_ERROR_STORAGE_NOT_AVAILABLE; break; case OPTEE_MSG_RPC_CMD_RPMB: optee_suppl_cmd_rpmb(dev, arg); diff --git a/include/tee.h b/include/tee.h index 98b1c9c..edd9f9b 100644 --- a/include/tee.h +++ b/include/tee.h @@ -34,6 +34,7 @@ * struct tee_version_data::gen_caps */ #define TEE_SUCCESS 0x00000000 +#define TEE_ERROR_STORAGE_NOT_AVAILABLE 0xf0100003 #define TEE_ERROR_GENERIC 0xffff0000 #define TEE_ERROR_BAD_PARAMETERS 0xffff0006 #define TEE_ERROR_ITEM_NOT_FOUND 0xffff0008
If OP-TEE core is compiled with support of REE FS and RPMB at the same time (CFG_RPMB_FS ?= y; CFG_RPMB_FS ?= y), and persistent storage API is used with TEE_STORAGE_PRIVATE storage id, it will lead to TA panic. E/TC:? 0 TA panicked with code 0xffff0009 ..... E/TC:? 0 Call stack: E/TC:? 0 0x000000004002f2f8 TEE_OpenPersistentObject at lib/libutee/tee_api_objects.c:422 In this particular case TEE_ERROR_STORAGE_NOT_AVAILABLE is more suitable than TEE_ERROR_NOT_IMPLEMENTED, as it provides to a TA a possibility to handle this error code [1]. From GPD TEE Internal Core specification [2]: TEE_ERROR_STORAGE_NOT_AVAILABLE - if the persistent object is stored in a storage area which is currently inaccessible. It may be associated with the device but unplugged, busy, or inaccessible for some other reason. [1]: https://github.com/OP-TEE/optee_os/blob/94db01ef448d1e552161c2d861d57a5f8bda0cc0/lib/libutee/tee_api_objects.c#L419 [2]: https://globalplatform.org/wp-content/uploads/2018/06/GPD_TEE_Internal_Core_API_Specification_v1.1.2.50_PublicReview.pdf Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org> --- drivers/tee/optee/supplicant.c | 4 ++-- include/tee.h | 1 + 2 files changed, 3 insertions(+), 2 deletions(-)