Tee-dev

tee-dev@lists.linaro.org

292 discussions

are shared buffers physically contiguous?

by Sören Brinkmann

Hi, I am playing with OP-TEE on ZynqMP and am working on a proof of concept for programming the FPGA from Linux through a TA in OP-TEE. The first questions I had where regarding how to access the necessary HW and I found: https://github.com/OP-TEE/optee_os/issues/404 https://lists.linaro.org/pipermail/tee-dev/2015-August/000160.html I guess a user-TA memory is completely isolated and hence the pointer to use a static TA? I actually got that part working and added a static TA that takes a temporal memref from the normal world. I.e. the flow is like this: 1. user space app opens bitstream file and does any kind of pre-processing that may be required 2. user-space application mmaps the bitstream file 3. user-space app populates a TEEC_Operation struct with a TEEC_TEMP_INPUT argument that holds the mmap address and the size of the file 4. user-space invokes TA 5. TA does some sanity checking, ... 6. TA looks up the physical address of the bitstream and flushes the cache 7. TA programs a DMA to transfer the bitstream into the FPGA This process does actually work, but I'm not sure how much luck is involved. The bitstream file for the device I'm working with is ca. 10MB large and for the DMA to work it needs to be present in memory in a physically contiguous address range (it could probably be programmed in chunks, but if not necessary I'd avoid going there). That rose the question: Is the data the TA works with guaranteed to be present in a physically continuous block? And if not, was there an easy way to achieve that? Thanks, Sören

8 years, 11 months

Shared memory allocated by tee linux kernel driver is not zeroed out

by machiry aravind

Hi all, Looks like the shared memory allocated by linux tee driver (via IOCTL TEE_IOC_SHM_ALLOC) is not zeroed out. I verified this by modifying tee_client_api.c for checking for non-null bytes in mmap memory in function: TEEC_AllocateSharedMemory. This could be exploited to leak data. Is there any reason why it is not Zeroed out? or Am i missing something? -Best, Aravind

8 years, 12 months

OPTEE OS : Param type not respected in mapping

by machiry aravind

Hi all, In optee-os, memory of all params is mapped RW, irrespective of paramType (viz, INPUT, OUTPUT or INOUT). References: https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/mm/tee_mmu.c#L… and https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/mm/tee_mmu.c#L… Do we know why is this so? I tried to change this to map R only for input, W for output and RW for inout. However few tests (ex: 4001 - 4007) in xtest suite fails.

8 years, 12 months

console_init in optee_os

by chinna 220

Hi - Can someone please help me answering the below? 1. What type of address CONSOLE_UART_BASE (defined in optee_os/core/arch/arm/plat-xxxxx/platform_config.h) represents? Physical (or) virtual address? void console_init(void) { pl011_init(CONSOLE_UART_BASE, CONSOLE_UART_CLK_IN_HZ, CONSOLE_BAUDRATE); } void pl011_init(vaddr_t base, uint32_t uart_clk, uint32_t baud_rate); 2. Are these consoles across different platforms assumed to be secure or non secure? Regards, Chinnabha

9 years

OP-TEE OS: Param Mapping in TA

by machiry aravind

Hi all, Is there any reason, why we expect all the memref param physical address to be in MEM_AREA_NSEC_SHM? More specifically, why is it hard to map arbitrary non-secure user-space pages into TA? MEM_AREA_NSEC_SHM restriction imposes unnecessary limit on TA. If I want to implement some integrity checking mechanism on large sections of memory, this restriction makes it almost impossible. -Best, Aravind

9 years

OPTEE-OS: Initialization of thread's core_mmu_use_map?

by machiry aravind

Hi all, I am trying to understand the memory mapping of threads in op-tee. I am unable to figure out, for all threads, where the initialization of user_map (struct core_mmu_use_map) happens? Relative path to the src file would be highly appreciated. Thank You, Aravind

9 years

Porting OP-TEE to xilinx zynq

by Bridges, Andy

Hi, While porting OP-TEE to Xilinx zynq-7000 ( 702 dev board ) I've hit a couple of issues which I'm hoping you might be able to help with. Issue 1 : If I have OP-TEE OS using both cores and core synchronisation at start-up, core 1 writes SEM_CPU_READY to sem_cpu_sync + 4, but core 0 reads 0 from sem_cpu_sync + 4. Issue 2: When OP-TEE OS for using only 1 core when it gets to the "rfefd sp!" in sm_smc_entry, it is not returning to the address specified in the mon_lr field of the sm_nsec_ctx structure for the core, which does match the address written to "lr" by the Xilinx FSBL before branching to OP-TEE for its initialisation. Regards Andy Bridges. ________________________________ Consider the environment before printing this mail. Thales UK Limited is incorporated in England and Wales with company registration number 00868273. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)1844 201800 and delete it and all copies from your system. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales UK Limited.

9 years

OPTEE BIG ENDIAN SUPPORT

by Shahaji Bhosle

Hi, Just wanted to check if any one has ported OPTEE_OS to BE system, also does that require ATF to be running in BE mode. Thanks, Shahaji

9 years

Porting OP-TEE to xilinx zynq

by Bridges, Andy

Hi, I have a few questions regarding porting OP-TEE to the Xilinx Zynq SoC. Q1 : Has anyone already successfully ported OP-TEE to the zynq ? if so where can I get the source from ? Q2 : What are the security & performance implications of building OP-TEE without the support for l2c-310/P310 enabled ? Q3 : Does the code for enabling the l2c-310/P310 support supplied for plat-stm work for all ARMv7 SoCs with a l2c-310/P310 if you remove the processor ID check and update the addresses appropriately ? Regards Andy Bridges ________________________________ Consider the environment before printing this mail. Thales UK Limited is incorporated in England and Wales with company registration number 00868273. Its registered office is located at 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 2NX. The information contained in this e-mail is confidential. It may also be privileged. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee or the intended addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)1844 201800 and delete it and all copies from your system. Commercial matters detailed or referred to in this e-mail are subject to a written contract signed for and on behalf of Thales UK Limited.

9 years

64-bit TEE

by David Brown

Looking at the TEE_Param definition: typedef union { struct { void *buffer; uint32_t size; } memref; struct { uint32_t a; uint32_t b; } value; } TEE_Param; there seems to be an implicit assumption of 32-bit pointers. There are two things going on here: - The 'memref' struct is larger than the 'value' structure, since the 'void *' is 8-bytes long on a 64-bit target. - The 'size' field is a uint32_t, which causes a pointer mismatch with a lot of API calls that are looking for a size_t. The first is only an issue if either we are expecting this param to be a specific size, or we expect some kind of correlation between 'buffer' and 'a', and 'size' and 'b'. The second means that instead of being able to use &param[n].memref.size, it is necessary to do something like: uint32_t local_size; ... local_size = param[n].memref.size; result = call(..., &local_size, ...); param[n].memref.size = local_size; in addition to security concerns with overflow on the size fields. My question then, how do we want to handle this? Assuming we want to make the TEE 64-bit compatible, what is the right answer? As well, what do relevant standards/specs say about this type (the file right above this definition says based on "GP TEE Internal API Specification Version 0.11", which I have not seen). Thanks, David

9 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev