OP-TEE is an Open Source TEE and is the result of collaboration work between STMicroelectronics and Linaro Security Working Group. It contains the complete stack from normal world client API's (optee_client), the Linux kernel TEE driver (optee_linuxdriver), the Trusted OS + the secure monitor (optee_os) and the test suite (xtest).
We have decided to keep all information related to building, flashing, etc, within the Git itself. Therefore, please have a look at the README.md file at GitHub to start with. As the project at GitHub evolves we will update with additional links here.
Where is the source code?
Under what license is it released?
How do I contribute?
Where can I get help?
- Via one of the avenues below:
- create a new issue for a relevant repository on our github site
- #linaro-security irc channel (url: irc.linaro.org or irc.freenode.net, ssl: yes, port: 6697)
- op-tee at linaro dot org
- for linaro member companies, https://support.linaro.org
What API's has been implemented in OP-TEE?
Will Linaro be involved in GlobalPlatform certification/qualification?
No we will not. But since OP-TEE is coming from a proprietary TEE solution that was GlobalPlatform certified on some products in the past we know that the gap to become GlobalPlatform certified isn't that big.
Which architectures are supported?
It has been developed and tested on ARMv7-A architecture. We have also added support for ARMv8-A platforms (FVP, Juno, HiKey, MTK and several other member boards).
32-bit and/or 64-bit support?
- Both 32- and 64-bit are fully supported for all OP-TEE components.
How do I port OP-TEE to another platform?
Start by reading the slide set from LCU14 that could be found here. There is also a YouTube clip from that session that could be found here. A good reference for this is also the patch that adds support for Allwinners A80 Armv7-a board to OP-TEE. For Armv8, this patch adds support for Juno.
How do I write a Trusted Application (TA)?
Start by reading the slide set from LCU14 that could be found here. There is also a YouTube clip from that session that could be found here. Apart from the hello world application mentioned in the slide set we have also created another example that uses buffers and GlobalPlatform API's, which also comes with some documentation about how the Trusted Application communicates with the different software components. This Trusted Application could be found here.
How do I write a Trusted Application (TA) v2?
This hello_world is a good place to start.
The GlobalPlatform specs defining the APIs used are here. Start with TEE Client API Specification, and see how the APIs are used in https://github.com/linaro-swg/hello_world/blob/master/host/main.c. Then look at TEE Internal Core API Specification (especially Section 4.3) and see how these are applied in https://github.com/linaro-swg/hello_world/blob/master/ta/hello_world_ta.c.
How do I write a static TA?
Use this as an example:
- define a UUID for your TA and the command ID
define static_ta_register with your entry-point functions
Why isn't the kernel driver in the vanilla kernel at kernel.org?
The intention is to upstream it as soon as possible, however, even though the driver is working as it should it still needs adaptation to meet the requirements for source code in the Linux kernel, this work and the upstreaming work is handled in Jira SWG-3 (member-access only).
How are you testing OP-TEE?
There is a test suite called xtest that tests the complete TEE-solution to ensure that the communication between all architectural layers are working as they're supposed to do. The test suite also tests the majority of the GlobalPlatform TEE Internal API. It has close to 50000 and ever increasing test cases, and also extendable with the official GlobalPlatform test suite.
Where do I download the test suite?
How are Trusted Applications verified?
ta_load >> ta_store->open >> ta_open >> check_shdr >> crypto_ops.acipher.rsassa_verify. For the original pull request (which is now outdated), see this patch. This URL also gives more details about the signed header format.
Is multi-core TA supported?
Is multi-threading supported in a TA?
- No, there is no such concept as pthreads or similar. I.e, you cannot spawn thread from a TA. If you need to run tasks in parallel, then you should probably look into running two TAs or more simultaneously and then let them communicate with each other using the TA2TA interface.
Can I use my own hardware IP for crypto acceleration?
Yes, OP-TEE has a crypto abstraction layer that was designed mainly to make it easy to add support for hardware crypto acceleration. On this URL you will find information about the abstraction layer and what you would need to do to be able to add support new software/hardware "drivers" in OP-TEE.
What’s the maximum size for heap and stack? Can it be changed?
- Yes, that can be changed. In the current setup (for vexpress as an example), there are 32MB DDR dedicated for OP-TEE. 1MB for TEE RAM and 1MB for PUB RAM, this leaves 30MB for Trusted Applications. In the Trusted Applications, you set TA_STACK_SIZE and TA_DATA_SIZE. Typically we set stack to 2KiB and data to 32KiB. But you are free to adjust those according to the amount of memory you have available.
What is the size of OP-TEE itself?
As of 2016.01, optee_os is about 244KB (release build), but the goal is to eventually reduce it to less than 128KB. It is preferred to store optee_os in SRAM, but if there is not enough room, DRAM can be used and protected with TZASC.
We are also looking into the possibility of creating a 'minimal' OP-TEE, i.e. a limited OP-TEE usable even in a very memory constrained environment, by eliminating as many memory-hungry parts as possible. There is however no ETA for this at the moment.
Can neon optimizations be done in OP-TEE?
Yes, but it will require implementation of lazy context switching which Linaro is currently working on as part of the work to add support for ARMv8 crypto extensions. For more information about lazy context switching, click here.
Can I use C++ libraries in OP-TEE?
- C++ libraries are currently not supported. Technically, it is possible, but will require a fair amount of work to implement, especially more so if exceptions are required. There are currently no plans to do this.
Does OP-TEE support mixed-mode, i.e., both AArch32 and AArch64 trusted applications on top of an AArch64 core?
Would using malloc() in OPTEE give physically contiguous memory?
- malloc() in OP-TEE currently gives physically contiguous memory. It is not guaranteed as it is not mentioned anywhere in the documentation, but in practice the heap only has physically contiguous memory in the pool(s). The heap in OP-TEE is normally quite small, ~24KiB, and could be a bit fragmented.
Are static user space TAs supported?
What can I do to access specific functionalities not part of the GP Internal API?
You may develop your own "static TA", which is part of the core, and can access any function of the core. Current static TAs can be found here. BUT, please be aware that static TAs run in kernel mode, so one has to be careful when using them.
What exactly is a static TA anyway? How different is it than a regular GlobalPlatform defined (dynamic) TA?
A static TA is just an interface exposing special services in optee_os core to dynamic TAs and clients. It is code inside the TEE core. As such, it does not have its own address space and can corrupt the whole TEE if poorly written. Also it is usually more difficult to upgrade than a dynamic (user) TA which is a file in the normal world file system.
On the other hand, a static TA can access the hardware directly by calling any driver code inside the TEE core. This means you may use a static TA to extend the services offered by the GP Internal API, without adding any new system call.
Client Applications (CAs) in the normal world can communicate with static TAs in the same way they communicate with dynamic TAs. Dynamic TAs can also communicate with static TAs in the same way they communicate with other dynamic TAs, using GP Internal API. Static TAs, however, cannot communicate back to dynamic TAs due to the absence of GP Internal API in optee_os core code.
Can I limit what CPUs OP-TEE runs on?
- Right now it's up to the kernel to decide which core it runs on, i.e, it will be the same core as the one initiating the SMC in Linux.
How can I use or call OP-TEE (GlobalPlatform) APIs from an Android (.apk) app?
Use JNI. First get familiar with https://developer.android.com/ndk/samples/sample_hellojni.html and make sure you can run the example. After that, replace the C-side Implementation with say https://github.com/linaro-swg/hello_world or one of the examples in https://github.com/linaro-swg/optee_examples. Note that hello_world and optee_examples are built as executables, and have to be modified to be built as a .so shared library instead so that it can be loaded by the Java-side Implementation.
Note that .apk apps by default have no access to the TEE driver. See https://github.com/OP-TEE/optee_os/issues/903 for details. The workaround is to disable SELinux before launching any .apk app that calls into OP-TEE. The solution is to create/write SELinux domains/rules to allow any required access, but since this is not a TEE-related issue, it is left as an exercise for the users.
- OP-TEE - Open Portable TEE
- TEE - Trusted Execution Environment
Last Updated: 2016-04-22
WorkingGroups/Security/OP-TEE (last modified 2017-12-06 08:25:04)