Tee-dev

tee-dev@lists.linaro.org

291 discussions

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

7 years, 11 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.

7 years, 11 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

7 years, 11 months

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

7 years, 11 months

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

7 years, 11 months

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.

7 years, 11 months

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

7 years, 11 months

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.

7 years, 12 months

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

8 years

Query regarding ARM PSCI interface enablement in OP-TEE.

by SUMIT GARG

Hi OP-TEE Experts, We are trying to enable ARM PSCI interface in OP-TEE for ARMv7 based Freescale LS1021a SoC (Platform - ls). If anyone has done some prior work or working on how to enable ARM PSCI interface in OP-TEE, kindly share it. Also if someone can clarify the standard way to enable ARM PSCI interface for turning-on/off secondary CPUs, it would be very much appreciated. Thanks and regards, Sumit

8 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev