You can find both the generic TEE framework (including the OP-TEE) driver included in the official Linux kernel project since v4.12. Having that said, we “buffer up” pending patches on a our Linux kernel OP-TEE (branch: optee). I.e., that is where we keep new features being developed for OP-TEE. In the long run we aim to completely stop using our own branch and just send all patches to the official Linux kernel tree directly. But as of now we cannot do that.
What did you try to build? Only optee_os? A full setup using QEMU, HiKey, RPi3, Juno using repo? AOSP? OpenEmbedded? What we build on daily basis are the OP-TEE repo setups, other builds like AOSP and OpenEmbedded are builds that we try from time to time, but not very often within Security Working Group. Having that said there are other teams in Linaro working with such builds, but they most often base their builds on OP-TEE stable releases.
By running latest instead of stable also comes with a risk of getting build errors due to version and/or interdependency skew which can result in build error. Now, such issues most often affects running xtest and not the building. If you however clean all gits and do a
repo sync -d. Then we’re almost 100% sure you will get back to a working state again, since as mentioned in next bullet, we build (and run xtest) on all QEMU on all patches sent to OP-TEE.
Every pull request in OP-TEE are built for a multitude of different platforms automatically using Travis for OP-TEE. Please have a look there to see whether it failed building on the platform you’re using before submitting any issue about build errors.
Once a day Travis builds all repo setups (manifests) automatically and the results for the builds can be found at the Travis OP-TEE build page.
Stable releases are quite well tested both in terms of building for all supported platforms and running xtest on all platforms, so if you cannot get that to build and run, then there is a great chance you have something wrong on your side. All platforms that has been tested on a stable release can be found in CHANGELOG.md file.
g++ XYZcompiler error messages?
Most likely you’re trying to build OP-TEE using the regular x86 compiler and not the using the ARM toolchain. Please install the OP-TEE pre-requisties and this time try to ensure that you are using GCC for ARM (for more information, please see Issue#846).
That git is used in conjunction with the OP-TEE repo setups. It contains helper makefiles that makes it easy to get OP-TEE up and running on the setups that are using repo.
makefrom build.git it fails to download the toolchains?
We try to stay somewhat up to date with running later gcc versions. But just like everywhere else on the net things moves around. In some cases like Issue#1195, the URL was changed without us noticing it. If you find and fix such an issue, please send the fix as pull request and we will be happy to merge it.
That would be running it on QEMU on a local PC. To do that you would need to:
By summarizing the above, you would need to:
$ sudo apt-get install [pre-reqs] $ mkdir optee-qemu && cd optee-qemu $ repo init -u https://github.com/OP-TEE/manifest.git $ repo sync $ cd build $ make toolchains -j3 $ make all run (qemu) c root@Vexpress:/ xtest
Since OP-TEE is a GlobalPlatform based TEE which implements the APIs as specified by GlobalPlatform one has to accept, the click-through license which is presented when trying to download the GlobalPlatform specifications before start using OP-TEE.
That is something we deal with case by case. But as a general answer, if it does not contaminate the BSD 2-Clause license we will accept it. Send us an email or file an issue at OP-TEE Issues.
Please see the section “Contributions” in the file Notice.md at the GitHub project page.
Via one of the avenues below:
#linaro-securityIRC channel (
ssl: yes, port: 6697)
<op-tee at linaro dot org>
repofor the device in Platforms Supported currently not using repo.
If your company has done significant contributions to OP-TEE, then please send us an email and we will do our best to include your company. Pay attention to that we will review this on regular basis and inactive supporting companies might be removed in the future again.
Send an email to us (see the Security Advisories page), where you mention that you have found a vulnerability, no details are needed in this first email. After that someone in the team will contact you and let you know how to continue the communication securely.
No we will not, mainly for two reasons. The first is that there was a board decision that Security WG in Linaro should not be part of certifications. The second reason is that most often certification is done using a certain software version and on a unique device. I.e., it is the combination software + hardware that gets certified. Since Linaro have no own devices in production or for sale, we cannot be part of any certification. This is typically something that the SoC or OEM needs to do.
But since OP-TEE is coming from a proprietary TEE solution that was GlobalPlatform certified on some products in the past and we regularly have people from some member companies running the extended test suite from GlobalPlatform we know that the gap to become GlobalPlatform certified/qualified isn’t that big.
All those specification can be found at GlobalPlatform specifications page.
Yes, OP-TEE has a Crypto Abstraction Layer that was designed mainly to make it easy to add support for hardware crypto acceleration. There you will find information about the abstraction layer itself and what you need to do to be able to support new software/hardware “drivers” in OP-TEE.
The Platforms Supported page lists all platforms and architectures currently supported in the official tree.
Both 32- and 64-bit are fully supported for all OP-TEE components.
To-Do mention the configuration flags for NW/SW/TEE/TA etc.
Yes, it can be changed. In the current setup (for vexpress for example), there are
32MB DDR dedicated for OP-TEE.
TEE RAM and
PUB RAM, this leaves
30MB for Trusted Applications. In the Trusted Applications, you set
TA_DATA_SIZE. Typically, we set stack to
1KB and data to
32K. But you are free to adjust those according to the amount of memory you have available. If you need them to be bigger than
1MB then you also must adjust TA’s MMU L1 table accordingly, since default section mapping is 1MB.
As of 2016.01, optee_os is about
244KB (release build). 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.
You can check the memory usage by using the
make mem_usage target in optee_os, example:
$ make ... mem_usage # Which will output a file with the figures here: # out/arm/core/tee.mem_usage
You will of course get different sizes depending on what compile time flags you have enabled when running
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-A Crypto Extensions. You can read more about Lazy Context Switching at the ARM pages. Please also see Issue#953.
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.
malloc()in OP-TEE 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.
Currently 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. Please also see Issue#1194.
/lib/optee_armtz, that is the default configuration where tee-supplicant will look for Trusted Applications.
A Psuedo TA is OP-TEE firmware service offered through the generic API used to invoke Trusted Applications. Pseudo TA interface and services all runs in TEE kernel / core context. I.e., it will have access to the same functions, memory and hardware etc as the TEE core itself. If we’re talking ARMv8-A it is running in S-EL1.
You may develop your own “Psuedo TA”, which is part of the core (see above for more information about the Psuedo TA).
In the current solution all TAs are signed (sign.py) with the same RSA key (default_ta.pem). This works as long as the end user is in charge of the system. But for a setup involving third parties, there is a need for a better way to deal with this. We have started to look into various ideas and one of them is OTrP.
One can also build a Trusted Application and embed its raw binary content into the OP-TEE firmware binary. At runtime, if invoked, the Trusted Application will be loaded from the OP-TEE firmware image instead of being fetched from the normal world and authenticated in the secure world. The feature is enabled from OP-TEE configuration directive CFG_EARLY_TA, described in the OP-TEE OS generic configuration script.
Yes, you can have two or more TAs running simultaneously. Please see also Issue#1194.
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.
Use JNI. First get familiar with sample_hellojni.html and make sure you can run the sample. After that, replace the C-side Implementation with say the Hello World Trusted Application or one of the examples in optee_examples. Note that the Hello World Trusted Application 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 Issue#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.
Those can only be shared are under NDA with Google and Microsoft. Linaro can help members of Linaro to get access to those. As of now, we cannot share it with non-members.
There is a test suite called xtest (optee_test) that tests the complete TEE-solution to ensure that the communication between all architectural layers is working as it should. The test suite also tests the majority of the GlobalPlatform TEE Internal Core API. It has close to 50,000 and ever increasing test cases, and is also extendable with the official GlobalPlatform test suite (see TEE Initial Configuration Compliance Test Suite v1.x).
Also every single pull request in OP-TEE are being tested automatically on QEMU using Travis for OP-TEE.