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
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
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
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
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.