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
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
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
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
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
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
==============================================================================
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
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
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
Hello,
My name is Peeratham and I'm new to OP-TEE.
I'm trying to setup OP-TEE on Raspberry Pi3. I was able to build and create
a bootable sd card. It was booting up with these message (captured using my
phone, just in case it might help with troubleshooting):
==========================================
JTAG (gpio) enabled
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 0
reading Image
10220544 bytes read in 868 ms (11.2 MiB/s)
reading bcm22710-rpi-3-b.dtb
13376 bytes read in 19 ms (687.5 KiB/s)
reading optee.bin
362824 bytes read in 47 ms (7.4 MiB/s)
## Flattened Device tree blob at 01700000
Booting using the fdt blob at 0x1700000
reserving fdt memory region: addr=0 size=1000
reserving fdt memory region: addr=8000000 size=2000000
Loading Device tree to 0000000039f2d000, end 0000000039f3343f ... OK
Starting kernel ...
## Transferring control to ARM TF (at address 8400000) (dtb at 39f2d000)...
==========================================
but then the next screen appears with Raspberry graphics up top and a
blinking cursor.
And the shell never comes up. So I was not able to continue with the rest
of the steps in
https://github.com/OP-TEE/build/blob/master/docs/rpi3.md#3-build-instructio…
Do you have any suggestions to get this to work?
Regards,
-Peeratham
