Tee-dev November 2017

tee-dev@lists.linaro.org

7 participants
5 discussions

[PATCH v1 00/14] tee: optee: add dynamic shared memory support

by Volodymyr Babchuk

From: Volodymyr Babchuk <vlad.babchuk(a)gmail.com> This patch series enables dynamic shared memory support in the TEE subsystem as a whole and in OP-TEE in particular. Global Platform TEE specification [1] allows client applications to register part of own memory as a shared buffer between application and TEE. This allows fast zero-copy communication between TEE and REE. But current implementation of TEE in Linux does not support this feature. Also, current implementation of OP-TEE transport uses fixed size pre-shared buffer for all communications with OP-TEE OS. This is okay in the most use cases. But this prevents use of OP-TEE in virtualized environments, because: a) We can't share the same buffer between different virtual machines b) Physically contiguous memory as seen by VM can be non-contiguous in reality (and as seen by OP-TEE OS) due to second stage of MMU translation. c) Size of this pre-shared buffer is limited. So, first part of this patch series adds generic register/unregister interface to tee subsystem. Next patches add necessary features into OP-TEE driver, so it can use not only static pre-shared buffer, but whole RAM to communicate with OP-TEE OS. [1] https://www.globalplatform.org/specificationsdevice.asp Jens Wiklander (2): tee: flexible shared memory pool creation tee: add register user memory Volodymyr Babchuk (12): tee: shm: add accessors for buffer size and page offset tee: shm: add page accessor functions tee: optee: Update protocol definitions tee: optee: add page list manipulation functions tee: optee: add shared buffer registration functions tee: optee: add registered shared parameters handling tee: optee: add registered buffers handling into RPC calls tee: optee: store OP-TEE capabilities in private data tee: optee: add optee-specific shared pool implementation tee: optee: enable dynamic SHM support tee: use reference counting for tee_context tee: shm: inline tee_shm getter functions drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 131 +++++++++++++++++++++- drivers/tee/optee/core.c | 160 +++++++++++++++++++++------ drivers/tee/optee/optee_msg.h | 38 ++++++- drivers/tee/optee/optee_private.h | 26 ++++- drivers/tee/optee/optee_smc.h | 7 ++ drivers/tee/optee/rpc.c | 72 ++++++++++-- drivers/tee/optee/shm_pool.c | 75 +++++++++++++ drivers/tee/optee/shm_pool.h | 23 ++++ drivers/tee/tee_core.c | 81 ++++++++++++-- drivers/tee/tee_private.h | 60 +--------- drivers/tee/tee_shm.c | 226 +++++++++++++++++++++++++++++++------- drivers/tee/tee_shm_pool.c | 165 +++++++++++++++++----------- include/linux/tee_drv.h | 184 ++++++++++++++++++++++++++++++- include/uapi/linux/tee.h | 30 +++++ 15 files changed, 1058 insertions(+), 221 deletions(-) create mode 100644 drivers/tee/optee/shm_pool.c create mode 100644 drivers/tee/optee/shm_pool.h -- 2.7.4

6 years, 4 months

eMMC driver in OP-TEE?

by Stuart Yoder

There is no storage controller driver in OP-TEE, as pointed out in the RPMB doc: There is no eMMC controller driver in OP-TEE. The device operations all have to go through the normal world. They are handled by the tee-supplicant process which further relies on the kernel's ioctl() interface to access the device. Is doing this a roadmap (or potential roadmap) item for OP-TEE? I'm wondering what discussions might have happened in the past, and if the idea has been rejected for some reason. Or, is it a potential future to do item? The use case would be if OP-TEE provided a secure key store, and access was need to that key store prior to normal world being available...for example, to store keys that encrypted the disk to be used by Linux. Thanks, Stuart

6 years, 4 months

Pager and ARMv8

by Volodymyr Babchuk

Hello, I wanted to play wit pager on my RCAR board. Just to see if I can fit it to my virtualization PoC. But, I can't start OP-TEE with it. I have found this check: #ifdef ARM64 #ifdef CFG_WITH_PAGER #error "Pager not supported for ARM64" #endif #endif /*ARM64*/ in multiple platform_config.h files. But it bothers my, that this check is being done in platform code, not in some common place. I tried to remove it from plat-rcar/platform_config.h (along with adding TZSRAM definition). All builds fine, but, predictably, does not work :-). I added KEEP_PAGER() there and here in now at least I can see some debug output. Right now it fails there: ERROR: [0x0] TEE-CORE: assertion '!((va | end) & SMALL_PAGE_MASK)' failed at core/arch/arm/mm/core_mmu.c:851 <init_mem_map> So, now I'm wondering: is it really that ARMv8 is not supported at all? Why there is no check in common code then? Or is it problem of my platform configuration? -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk(a)gmail.com

6 years, 5 months

[PATCH] optee: fix invalid of_node_put() in optee_driver_init()

by Jens Wiklander

The first node supplied to of_find_matching_node() has its reference counter decreased as part of call to that function. In optee_driver_init() after calling of_find_matching_node() it's invalid to call of_node_put() on the supplied node again. So remove the invalid call to of_node_put(). Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 58169e519422..18c8c0a50d37 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -589,7 +589,6 @@ static int __init optee_driver_init(void) return -ENODEV; np = of_find_matching_node(fw_np, optee_match); - of_node_put(fw_np); if (!np) return -ENODEV; -- 2.7.4

6 years, 5 months

[PATCH 0/3] tee: asynchronous supplicant requests

by Jens Wiklander

Hi, Currently all tee supplicant communication is synchronous. This isn't very limiting if the supplicant only is accessing system local resources like storage. With network access via the supplicant it becomes a larger problem. This patch set enables asynchronous communication with the supplicant by introducing meta parameters in the user space API. The meta parameters can be used to tag requests with an id that can be matched against an asynchronous response as is done here in the OP-TEE driver. Asynchronous supplicant communication is needed by OP-TEE to implement GlobalPlatforms TEE Sockets API Specification v1.0.1. The specification is available at https://www.globalplatform.org/specificationsdevice.asp. This change is backwards compatible allowing older supplicants to work with newer kernels and vice versa. Thanks, Jens Jens Wiklander (3): tee: add tee_param_is_memref() for driver use tee: add TEE_IOCTL_PARAM_ATTR_META optee: support asynchronous supplicant requests drivers/tee/optee/core.c | 11 +- drivers/tee/optee/optee_private.h | 43 ++--- drivers/tee/optee/rpc.c | 4 +- drivers/tee/optee/supp.c | 375 ++++++++++++++++++++++++-------------- drivers/tee/tee_core.c | 32 ++-- include/linux/tee_drv.h | 12 ++ include/uapi/linux/tee.h | 7 + 7 files changed, 295 insertions(+), 189 deletions(-) -- 2.7.4

6 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev November 2017