Tee-dev September 2017

tee-dev@lists.linaro.org

9 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, 11 months

A Quick Survey on a Patch Propagation Tool

by machiry aravind

Hi Developer and maintainers, We (researchers for UC Santa Barbara) are developing a tool that will help in propagating patches. Please, It would be great if you can fill a 2-question anonymous survey: https://goo.gl/forms/5cBSx4axKmc8BEtA3 Would you be interested in a tool, which identifies patches that could be imported with a minimal or rather no testing? E.g. Security patches, you can import security patches as they usually do not affect the functionality. This tool would use only old source file and the new source file!! No commit messages, no build setup, nothing!! Something like: git saferebase? We actually used the tool on the Linux Main Line repository and it did identify several (60%) patches which are safe to port or do not affect the functionality. This tool could be used to import patches from the main source branch to your branch without worrying about testing them. You can also use this tool as a patch monitor, which monitors all commits to a repository and inform you about patches that do not affect the functionality or otherwise safe patches. Note that: This tool is supposed to *help* an expert not to *replace* one. Thank You, Aravind

7 years, 2 months

A Quick Survey on a Patch Propagation Tool

by Aravind Machiry

Hi Developer and maintainers, We (researchers for UC Santa Barbara) are developing a tool that will help in propagating patches. Please, It would be great if you can fill a 2-question anonymous survey: https://goo.gl/forms/5cBSx4axKmc8BEtA3 Would you be interested in a tool, which identifies patches that could be imported with a minimal or rather no testing? E.g. Security patches, you can import security patches as they usually do not affect the functionality. This tool would use only old source file and the new source file!! *No commit messages, no build setup, nothing!!* Something like: git saferebase? This tool could be used to import patches from the main source branch to your branch without worrying about testing them. You can also use this tool as a patch monitor, which monitors all commits to a repository and inform you about patches that do not affect the functionality or otherwise safe patches. Thank You, Aravind

7 years, 2 months

[PATCH] Update link rules for User TA

by Pierre Peiffer

Let's use --start-group / --end-group to allow all libraries added by a user to use any symbols provided by optee-os lib without having to add that library again. For example, if one provides its own library libexample.a that use strcmp(), which is provided by libutils.a, and he want to compile its TA with libexample.a, he'll add libdirs += ... libnames += example in his TA Makefile But the linker will not find strcmp() symbol unless he adds utils lib explicitely: libnames += utils example even if it is already specified in ta_dev_kit.mk because the order matter, unless it uses -start-group / --end-group Signed-off-by: Pierre Peiffer <ppeiffer(a)invensense.com> --- ta/arch/arm/link.mk | 2 +- ta/mk/ta_dev_kit.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ta/arch/arm/link.mk b/ta/arch/arm/link.mk index 304bccc..ccd6467 100644 --- a/ta/arch/arm/link.mk +++ b/ta/arch/arm/link.mk @@ -25,7 +25,7 @@ reverse = $(if $(wordlist 2,2,$(1)),$(call reverse,$(wordlist 2,$(words $(1)),$( link-ldadd = $(LDADD) link-ldadd += $(addprefix -L,$(libdirs)) -link-ldadd += $(addprefix -l,$(call reverse,$(libnames))) +link-ldadd += --start-group $(addprefix -l,$(call reverse,$(libnames))) --end-group ldargs-$(binary).elf := $(link-ldflags) $(objs) $(link-ldadd) diff --git a/ta/mk/ta_dev_kit.mk b/ta/mk/ta_dev_kit.mk index fab5df0..aaa9fab 100644 --- a/ta/mk/ta_dev_kit.mk +++ b/ta/mk/ta_dev_kit.mk @@ -61,7 +61,7 @@ endif cppflags$(sm) += -I. -I$(ta-dev-kit-dir)/include libdirs += $(ta-dev-kit-dir)/lib -libnames += utils utee mpa utils zlib png utee +libnames += utils utee mpa zlib png libdeps += $(ta-dev-kit-dir)/lib/libutils.a libdeps += $(ta-dev-kit-dir)/lib/libmpa.a libdeps += $(ta-dev-kit-dir)/lib/libutee.a -- 2.7.4

7 years, 2 months

allocating memory for DMA

by Stuart Yoder

I am doing some experiments with a crypto device in the OP-TEE kernel. What is the recommended way to allocate physically contiguous memory for DMA? Will using malloc() in the kernel give me physically contiguous memory? ...based on what I see in documentation/optee_design.md it says that the heap is unpaged, which leads me to think that malloc gives contiguous memory, but wanted to confirm. Thanks, Stuart

7 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev September 2017