Searched hist:f5411aaf359b3bf848982403e16922217b1ef03f (Results 1 – 2 of 2) sorted by relevance
| /optee_os/core/tee/ |
| H A D | tee_ree_fs.c | f5411aaf359b3bf848982403e16922217b1ef03f Wed Aug 17 08:03:49 UTC 2022 Judy Wang <wangjudy@microsoft.com> core: add CFG_REE_FS_INTEGRITY_RPMB for roll-back protection of REE
If we enable CFG_RPMB_FS and CFG_REE_FS at the same time in optee-os,
with tee-supplicant only supports REE, calls from xtest to
ree_fs_open() will attempt to access RPMB for roll-back protection,
which will fail because tee-supplicant can't access RPMB.
In some platforms, we only want optee-os to support
RPMB key provision checking by invoking any RPMB read/writes, but
don't care about whether contents could be read/written.
The tee-supplicant in these platform is limited to REE only, because
there's an existing issue in Linux OS causing kernel drivers failed to
support RPMB. So we need an option to prevent applications like xtest
to access RPMB when calling ree_fs_open(), but keep the ability to
call RPMB fs related apis. When we check the key thru RPMB read.
If key is provisioned, tee-supplicant will return
TEEC_ERROR_ITEM_NOT_FOUND. If not, optee-os will return
TEE_ERROR_STORAGE_NOT_AVAILABLE.
How-tested: execute `xtest -t regression` with optee-os CFG_REE_FS=y
and CFG_RPMB_FS=y. optee-client RPMB_EMU=n
Many testcases will fail. (ex: case 1004)
Signed-off-by: Judy Wang <wangjudy@microsoft.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
|
| /optee_os/mk/ |
| H A D | config.mk | f5411aaf359b3bf848982403e16922217b1ef03f Wed Aug 17 08:03:49 UTC 2022 Judy Wang <wangjudy@microsoft.com> core: add CFG_REE_FS_INTEGRITY_RPMB for roll-back protection of REE
If we enable CFG_RPMB_FS and CFG_REE_FS at the same time in optee-os,
with tee-supplicant only supports REE, calls from xtest to
ree_fs_open() will attempt to access RPMB for roll-back protection,
which will fail because tee-supplicant can't access RPMB.
In some platforms, we only want optee-os to support
RPMB key provision checking by invoking any RPMB read/writes, but
don't care about whether contents could be read/written.
The tee-supplicant in these platform is limited to REE only, because
there's an existing issue in Linux OS causing kernel drivers failed to
support RPMB. So we need an option to prevent applications like xtest
to access RPMB when calling ree_fs_open(), but keep the ability to
call RPMB fs related apis. When we check the key thru RPMB read.
If key is provisioned, tee-supplicant will return
TEEC_ERROR_ITEM_NOT_FOUND. If not, optee-os will return
TEE_ERROR_STORAGE_NOT_AVAILABLE.
How-tested: execute `xtest -t regression` with optee-os CFG_REE_FS=y
and CFG_RPMB_FS=y. optee-client RPMB_EMU=n
Many testcases will fail. (ex: case 1004)
Signed-off-by: Judy Wang <wangjudy@microsoft.com>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
|