Tee-dev

tee-dev@lists.linaro.org

292 discussions

Re: [Tee-dev] comment about "unregistered" vs "register" shared memory

by Jens Wiklander

+tee-dev On Mon, Jun 12, 2017 at 10:11 AM, Jens Wiklander <jens.wiklander(a)linaro.org> wrote: > Hi Stuart, > > On Sat, Jun 10, 2017 at 12:12 AM, Stuart Yoder <stuart.yoder(a)arm.com> wrote: >> >> +Volodymyr (correcting corrupted email address) >> >> >> On 6/9/17 11:51 AM, Stuart Yoder wrote: >>> >>> All, >>> >>> I've been reviewing and trying out Volodymyr's patches related to dynamic >>> shared memory. >>> >>> One thing I found thoroughly confusing was that in the same capabilities list >>> we use the word "register" in two completely different ways. >>> >>> /* Secure world can communicate via previously unregistered shared memory */ >>> #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM (1 << 1) >>> /* Secure world supporst commands "register/unregister shared memory" */ >>> #define OPTEE_SMC_SEC_CAP_REGISTER_SHM (1 << 2) >>> >>> As far as I can tell "unregistered shared memory" simply means >>> "dynamic shared memory" vs a pre-allocated static region. >>> >>> It would be much clearer if we tweaked the names: >>> >>> /* Secure world can communicate via previously unregistered shared memory */ >>> #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM (1 << 1) >>> /* Secure world supporst commands "register/unregister shared memory" */ >>> #define OPTEE_SMC_SEC_CAP_CMD_REGISTER_SHM (1 << 2) >>> >>> Are you open to that change? > > I agree, what you're proposing is more clear. It's not an ABI change, > only how it's documented. Since we already have > OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM defined on the (optee_os) master > branch we do the change there via a pull request. > > If possible please create a pull request at github. > > Thanks, > Jens

8 years

[PATCH] tee: add forward declaration for struct device

by Jerome Forissier

tee_drv.h references struct device, but does not include device.h nor platform_device.h. Therefore, if tee_drv.h is included by some file that does not pull device.h nor platform_device.h beforehand, we have a compile warning. Fix this by adding a forward declaration. Signed-off-by: Jerome Forissier <jerome.forissier(a)linaro.org> --- include/linux/tee_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index 8614713..07bd226 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -29,6 +29,7 @@ #define TEE_SHM_DMA_BUF BIT(1) /* Memory with dma-buf handle */ #define TEE_SHM_EXT_DMA_BUF BIT(2) /* Memory with dma-buf handle */ +struct device; struct tee_device; struct tee_shm; struct tee_shm_pool; -- 2.7.4

8 years

comment about "unregistered" vs "register" shared memory

by Stuart Yoder

All, I've been reviewing and trying out Volodymyr's patches related to dynamic shared memory. One thing I found thoroughly confusing was that in the same capabilities list we use the word "register" in two completely different ways. /* Secure world can communicate via previously unregistered shared memory */ #define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM (1 << 1) /* Secure world supporst commands "register/unregister shared memory" */ #define OPTEE_SMC_SEC_CAP_REGISTER_SHM (1 << 2) As far as I can tell "unregistered shared memory" simply means "dynamic shared memory" vs a pre-allocated static region. It would be much clearer if we tweaked the names: /* Secure world can communicate via previously unregistered shared memory */ #define OPTEE_SMC_SEC_CAP_DYNAMIC_SHM (1 << 1) /* Secure world supporst commands "register/unregister shared memory" */ #define OPTEE_SMC_SEC_CAP_CMD_REGISTER_SHM (1 << 2) Are you open to that change? Thanks, Stuart

8 years

[RESEND PATCH] tee: optee: fix uninitialized symbol 'parg'

by Jens Wiklander

Fixes the static checker warning in optee_release(). error: uninitialized symbol 'parg'. Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> --- drivers/tee/optee/core.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 58169e519422..857141e29e80 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -224,13 +224,14 @@ static void optee_release(struct tee_context *ctx) if (!IS_ERR(shm)) { arg = tee_shm_get_va(shm, 0); /* - * If va2pa fails for some reason, we can't call - * optee_close_session(), only free the memory. Secure OS - * will leak sessions and finally refuse more sessions, but - * we will at least let normal world reclaim its memory. + * If va2pa fails for some reason, we can't call into + * secure world, only free the memory. Secure OS will leak + * sessions and finally refuse more sessions, but we will + * at least let normal world reclaim its memory. */ if (!IS_ERR(arg)) - tee_shm_va2pa(shm, arg, &parg); + if (tee_shm_va2pa(shm, arg, &parg)) + arg = NULL; /* prevent usage of parg below */ } list_for_each_entry_safe(sess, sess_tmp, &ctxdata->sess_list, -- 2.7.4

8 years, 1 month

Porting to new platform, hang after enabling MMU

by Akshay Bhat

Hi, Trying to port OP-TEE to Atmel SAMA5D2 board (ATSAMA5D2-XULT) - single core ARM A5. I do not see any serial messages after MMU gets enabled (bl cpu_mmu_enable), neither does op-tee go onto load linux kernel. Intended boot flow: at91bootstrap -> u-boot (loads tee.bin/zImage/dtb) -> op-tee -> kernel Things I have already verified: - UART is setup to use MEM_AREA_IO_NSEC and UART data is setup as __early_bss "static struct atmel_uart_data console_data __early_bss; register_phys_mem(MEM_AREA_IO_NSEC, CONSOLE_UART_BASE, CORE_MMU_DEVICE_SIZE);" - UART is setup to use virtual address after MMU is enabled "static vaddr_t chip_to_base(struct serial_chip *chip) { struct atmel_uart_data *pd = container_of(chip, struct atmel_uart_data, chip); return io_pa_or_va(&pd->base); } static void atmel_uart_putc(struct serial_chip *chip, int ch) { vaddr_t base = chip_to_base(chip); while (!(read32(base + ATMEL_UART_SR) & ATMEL_SR_TXRDY)) ; write32(ch, base + ATMEL_UART_THR); }" - CFG_WITH_PAGER is not set - CFG_WITH_LPAE is not set - CFG_PL310 is not set (both in u-boot and in op-tee) - u-boot/kernel is setup to not use the DDR memory address range which op-tee uses (32MB space, 0x3E000000 to 0x40000000) - Issue seen with both master branch and 2.4.0 tag - Printing a message immediately after bl cpu_mmu_enable does not show up. "bl ugly_trace -> prints correctly bl cpu_mmu_enable bl ugly_trace -> does not print void ugly_trace(void); void ugly_trace(void) { MSG("ugly trace"); }" Log: DEBUG: [0x5f5ed35e] TEE-CORE:add_phys_mem:324: CFG_SHMEM_START type NSEC_SHM 0x3e000000 size 0x00400000 DEBUG: [0x5f5ed35e] TEE-CORE:add_phys_mem:324: CFG_TA_RAM_START type TA_RAM 0x3e500000 size 0x01b00000 DEBUG: [0x5f5ed35e] TEE-CORE:add_phys_mem:324: CFG_TEE_RAM_START type TEE_RAM 0x3e400000 size 0x00100000 DEBUG: [0x5f5ed35e] TEE-CORE:add_phys_mem:324: CONSOLE_UART_BASE type IO_NSEC 0xf8000000 size 0x00200000 DEBUG: [0x5f5ed35e] TEE-CORE:add_va_space:363: type RES_VASPACE size 0x00a00000 DEBUG: [0x5f5ed35e] TEE-CORE:dump_mmap_table:476: type TEE_RAM va 0x3e400000..0x3e4fffff pa 0x3e400000..0x3e4fffff size 0x00100000 (pgdir) DEBUG: [0x5f5ed35e] TEE-CORE:dump_mmap_table:476: type TA_RAM va 0x3e500000..0x3fffffff pa 0x3e500000..0x3fffffff size 0x01b00000 (pgdir) DEBUG: [0x5f5ed35e] TEE-CORE:dump_mmap_table:476: type NSEC_SHM va 0x40000000..0x403fffff pa 0x3e000000..0x3e3fffff size 0x00400000 (pgdir) DEBUG: [0x5f5ed35e] TEE-CORE:dump_mmap_table:476: type IO_NSEC va 0x40400000..0x405fffff pa 0xf8000000..0xf81fffff size 0x00200000 (pgdir) DEBUG: [0x5f5ed35e] TEE-CORE:dump_mmap_table:476: type RES_VASPACE va 0x40600000..0x40ffffff pa 0x00000000..0x009fffff size 0x00a00000 (pgdir) MESSAGE: [0x5f5ed35e] TEE-CORE:core_init_mmu_regs:822: TTBR0 = 0x3e45404a MESSAGE: [0x5f5ed35e] TEE-CORE:core_init_mmu_regs:823: TTBR1 = 0x3e45404a MESSAGE: [0x5f5ed35e] TEE-CORE:ugly_trace:52: ugly trace Any pointers on what to check next is appreciated. Thanks, Akshay

8 years, 1 month

problems with full system build on juno R2

by Stuart Yoder

Hi. I have a Juno R2 board and followed the process described here: https://github.com/OP-TEE/build/blob/master/README.md ...to build op-tee and all the other related components. I copied all the relevant bits to my Juno to update the firmware and other images but things hang here: [cut] NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.2(release):0d6e84b NOTICE: BL1: Built : 17:32:54, May 3 2017 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.2(release):0d6e84b NOTICE: BL2: Built : 17:32:54, May 3 2017 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.2(release):0d6e84b NOTICE: BL31: Built : 17:32:54, May 3 2017 So, it appears the bootloader never gets started. Anyone have ideas as to what I might be missing? ...I'll start further analysis and debug, but was expecting the canned build process to produce something that worked out of the box. Thanks, Stuart

8 years, 2 months

Question about tee /dev entries

by Stuart Yoder

All, I am new to secure world and op-tee and one thing I’m trying to understand is what the /dev/teeN and /dev/teeprivN device files in Linux conceptually represent. I’ve run the QEMU-based example, and I can see that /dev/tee0 and /dev/teepriv0 exist and the app uses tee0 and the supplicant uses teepriv0. What if I want to run multiple app/TA pairs at the same—do all open and share share the same /dev/tee0 file? If so, what is the scenario where you would ever have a /dev/tee1 and so on. From what I can see, the Linux driver is creating just one pair of device files. Do app/TAs always function in pairs? Is there ever a case where a “helloworld” TA was loaded once, and then multiple normal world apps would use it? …or, is it that an app that needs a secure TA service always loads the corresponding TA itself, even if it meant duplicating the TA. Thanks, Stuart

8 years, 3 months

[ANNOUNCE] Linux Security Summit 2017 - CFP

by James Morris

============================================================================== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT 2017 14-15 September LOS ANGELES, USA ============================================================================== DESCRIPTION The Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. LSS this year will be co-located with the Open Source Summit and the Linux Plumbers Conference. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length, including at least 10 minutes of discussion. * Discussion Topics: 30 minutes in length. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity control * Hardware Security * Iot and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: http://events.linuxfoundation.org/events/linux-security-summit/program/cfp DATES * CFP Close: June 5, 2017 * CFP Notifications: June 12, 2017 * Schedule Announced: June 19, 2017 * Slide Submission: August 31, 2017 WHO SHOULD ATTEND We're seeking a diverse range of attendees, and welcome participation by people involved in Linux security development, operations, and research. The LSS is a unique global event which provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It’s also useful for those who wish to keep up with the latest in Linux security development, and to provide input to the development process. WEB SITE http://events.linuxfoundation.org/events/linux-security-summit TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit PROGRAM COMMITTEE The program committee for LSS 2017 is: * James Morris, Oracle * Serge Hallyn, Canonical * Paul Moore, Red Hat * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org

8 years, 3 months

Clang build with sanitizers

by Krzysztof Kwiatkowski

Hi guys, I have maybe dumb question, so please forgive me but I'm not really expert in this topic. I think it would be interesting to use valgrind (memcheck) for testing OP-TEE. It actually seems not really possible/super complicated/I don't know how to do it. But any idea if it would be possible be possible to compile whole thing in clang with interesting sanitizers enabled? Then I would like to run tests on TEE and be somehow notified if sanitizer detects an error. Do you know if somebody have done it already? Kris

8 years, 5 months

Raspberry Pi 3 and OP-TEE

by Noam Camiel

Hi, I would like to try OP-TEE on the Raspberry Pi 3.I read in http://linuxgizmos.com/trustzone-tee-tech-ported-to-raspberry-pi-3/ that I would need a bus blaster and a custom cable for bare metal debugging.Would it be possible to point me where to get those? Is there one you can recommend? Is there any documentation on how to set it up from scratch on the Raspberry Pi?Thanks,Noam

8 years, 5 months

← Newer
1
...
21
22
23
24
25
26
27
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Tee-dev