Tee-dev July 2015

tee-dev@lists.linaro.org

5 participants
3 discussions

ATF (or Secure-run-time firmware) flow during switch from tee-driver to tee-os on ARMv7 SoC

by Sharma Bhupesh

Hi TEE Experts, We are trying to setup the optee-demo on a ARMv7 based Freescale SoC. During the same, I noticed that the SMC calls from the optee-linux-driver directly land up on the optee-os side. I was thinking that just like the ARMv8 flow, where the SMC handling should ideally be done by a Arm Trusted Firmware (or an equivalent secure-run-time firmware) agent running in EL3 privilege level, on ARMv7 too, if we have a resident ATF (or secure firmware) installed the SMC calls should be handled there. In the opteep-design documentation can the references to SECURE MONITOR LAYER (see [1]) be assumed to be equivalent to a ATF like firmware. Is this understanding correct or am I missing something here? [1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md Regards, Bhupesh

8 years, 10 months

[PATCH v4 preview 2 0/5] generic TEE subsystem

by Jens Wiklander

Hi, Here's preview 2 of the patchset I'm intending to send as PATCH v4 to the kernel mailing lists later. I've addressed previous comments applicable for the scope of this patchset. Please take a look to see that we're moving in the right direction. The "arm/arm64: add smccc ARCH32" patch doesn't contain complicated code, but the usage of Kconfig deserves some extra attention. OP-TEE patches to work with this in: https://github.com/jenswi-linaro/optee_client/tree/drv4_wip2 https://github.com/jenswi-linaro/optee_os/tree/drv4_wip2 https://github.com/jenswi-linaro/optee_test/tree/drv4_wip2 The kernel patches are also available at https://github.com/jenswi-linaro/linux/tree/gen_optee_driver4_wip2 v4 preview 2: * Redesigned the synchronization around entry exit of normal SMC (again) * Replaced rwsem with kref and completion since rwsem wasn't intended to be used in this way * Replaced semaphores with completions * Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for additional parameter types * Some RPC cleanup, don't use struct optee_msg_arg::func for instance * Changed tee_shm_pool_alloc_res_mem() to allow greater flexibility when defining driver private and dma-buf shared memory v4 preview 1: * Documents TEE subsystem and OP-TEE driver * Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE, TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION * DT bindings in a separate patch * Assembly parts moved to arch/arm and arch/arm64 respectively, in a separate patch * Redesigned the synchronization around entry exit of normal SMC * Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED * Removed CMA usage to limit the scope of the patch set v3: * Rebased on 4.1-rc3 (dma_buf_export() API change) * A couple of small sparse fixes * Documents bindings for OP-TEE driver * Updated MAINTAINERS v2: * Replaced the stubbed OP-TEE driver with a real OP-TEE driver * Removed most APIs not needed by OP-TEE in current state * Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h * Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc() * Moved tee.h into include/uapi/linux/ * Redefined tee.h IOCTL macros to be directly based on _IOR and friends * Removed version info on the API to user space, a data blob which can contain an UUID is left for user space to be able to tell which protocol to use in TEE_IOC_CMD * Changed user space exposed structures to only have types with __ prefix * Dropped THIS_MODULE from tee_fops * Reworked how the driver is registered and ref counted: - moved from using an embedded struct miscdevice to an embedded struct device. - uses an struct rw_semaphore as synchronization for driver detachment - uses alloc/register pattern from TPM Thanks, Jens Jens Wiklander (5): arm/arm64: add smccc ARCH32 dt/bindings: add bindings for optee tee: generic TEE subsystem tee: add OP-TEE driver Documentation: tee subsystem and op-tee driver Documentation/00-INDEX | 2 + Documentation/devicetree/bindings/optee/optee.txt | 17 + .../devicetree/bindings/vendor-prefixes.txt | 1 + Documentation/ioctl/ioctl-number.txt | 1 + Documentation/tee.txt | 117 +++ MAINTAINERS | 14 + arch/arm/Kconfig | 4 + arch/arm/kernel/Makefile | 2 + arch/arm/kernel/smccc-call.S | 26 + arch/arm/kernel/smccc.c | 17 + arch/arm64/Kconfig | 4 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/smccc-call.S | 34 + arch/arm64/kernel/smccc.c | 17 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/tee/Kconfig | 18 + drivers/tee/Makefile | 4 + drivers/tee/optee/Kconfig | 8 + drivers/tee/optee/Makefile | 5 + drivers/tee/optee/call.c | 390 ++++++++++ drivers/tee/optee/core.c | 451 +++++++++++ drivers/tee/optee/optee_msg.h | 334 ++++++++ drivers/tee/optee/optee_private.h | 129 ++++ drivers/tee/optee/optee_smc.h | 466 ++++++++++++ drivers/tee/optee/rpc.c | 248 ++++++ drivers/tee/optee/supp.c | 212 ++++++ drivers/tee/tee.c | 839 +++++++++++++++++++++ drivers/tee/tee_private.h | 80 ++ drivers/tee/tee_shm.c | 324 ++++++++ drivers/tee/tee_shm_pool.c | 133 ++++ include/linux/arm-smccc.h | 80 ++ include/linux/tee_drv.h | 306 ++++++++ include/uapi/linux/tee.h | 376 +++++++++ 34 files changed, 4663 insertions(+) create mode 100644 Documentation/devicetree/bindings/optee/optee.txt create mode 100644 Documentation/tee.txt create mode 100644 arch/arm/kernel/smccc-call.S create mode 100644 arch/arm/kernel/smccc.c create mode 100644 arch/arm64/kernel/smccc-call.S create mode 100644 arch/arm64/kernel/smccc.c create mode 100644 drivers/tee/Kconfig create mode 100644 drivers/tee/Makefile create mode 100644 drivers/tee/optee/Kconfig create mode 100644 drivers/tee/optee/Makefile create mode 100644 drivers/tee/optee/call.c create mode 100644 drivers/tee/optee/core.c create mode 100644 drivers/tee/optee/optee_msg.h create mode 100644 drivers/tee/optee/optee_private.h create mode 100644 drivers/tee/optee/optee_smc.h create mode 100644 drivers/tee/optee/rpc.c create mode 100644 drivers/tee/optee/supp.c create mode 100644 drivers/tee/tee.c create mode 100644 drivers/tee/tee_private.h create mode 100644 drivers/tee/tee_shm.c create mode 100644 drivers/tee/tee_shm_pool.c create mode 100644 include/linux/arm-smccc.h create mode 100644 include/linux/tee_drv.h create mode 100644 include/uapi/linux/tee.h -- 1.9.1

8 years, 10 months

Review PATCH v4

by Pascal Brand

Hello Jens, Here are some comments on patch V4. *smccc_call32* Do we only target aarch32 optee_os? *Buffer management* It looks that temporary buffers are now managed in the client API, not in the driver anymore. The positive point is that it makes the driver lighter. But the drawbacks is the number of extra ioctl used when using a temporary buffer: 1 to allocate, 1 to map, and 1 to unmap. So a TEEC_InvokeCommand could lead to 13 ioctls. What about the performances? Could not it be optimized in some way? Could we manage temporary buffers, dma buffers and "other" buffers in different ways? *Kernel API* The GP API looks managed in the Client part now, without a 1-to-1 mapping in kernel side. That means that we have lost the Kernel API, which is useful when a given driver wants to use a TA. It looks we are really missing this Kernel API. This is the most critical point of our review. *Non-zero copy* When using RegisterSharedMemory(), it looks we do not benefit from the fact that the original buffer was allocated using dma_buf. Hence we never have zero-copy in the current version when using RegisterSharedMemory as we will furher use the so-called shadowbuffer. Can you confirm this limitation can be removed in further versions of the patch? By the way, we think xtest 5006, which calls TEEC_RegisterSharedBuffer() twice may lead to memory leaks (it could be the same with the current optee_linuxdriver). *List of SHM* The list of the SHM allocated is now contained in the device, whereas it used to be in the context in optee_linuxdriver. This is not clear to us whether this is an issue or not. *tee_shm_pool_alloc_res_mem()* If we'd like to use the generic function for a LX backend, we would need to add the following arguments to the function: - the alignment of the private region, and the one of the dma region - a way to give the limits between both region (the size of the 1st region, or anything else). Emmanuel and I would like to check few other points in the proposal. We'll come back to you if we have any other remarks. Best regards, Jean Michel / Emmanuel / Etienne / Pascal

8 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev July 2015