Earlier this month, we ran a webinar about OP-TEE titled “ TEE kernel support is now upstream: What this means for Open Source Security”. There were over eighty participants with many more people watching the video afterwards. So many great questions were raised in the Q&A at the end of the webinar, that we unfortunately ran out of time to answer them all. We said that we would answer those remaining questions after the webinar, and here are the answers.
We are publishing the answers as a blog post for two reasons. Firstly, some questions overlapped, meaning several people are interested in the same answer. Secondly, the technical depth of the questions and the broad range of topics that they cover give an interesting overview as to what people are looking to do with OP-TEE.
The webinar and slide deck are here:
Q: Where to configure memory for TEE environment? Who decides that bootloader or TEE OS ?
A: Partly answered in the video, but in general we configure Trusted SRAM and DDR in the platform specific configuration files (search for CFG_TEE_RAM_START and CFG_DDR_START in optee_os).
Q: Is it possible to allocate a chunk of RAM in normal world and then turn it into secure memory which can be used for DRM pipeline, for instance?
A: Answered in the video. Currently we have the patches out of tree, but intend to upstream them as soon as the ongoing ION de-staging has been completed. Our patches can be found here: https://github.com/linaro-swg/linux/pull/35/commits and you will also find them merged in our development branch: https://github.com/linaro-swg/linux (branch “optee”). It can be worth having a look at optee_test also to see how we are testing Secure Data Patch, i.e., follow the code from here: https://github.com/OP-TEE/optee_test/blob/master/host/xtest/xtest_main.c#L68-L70
Q: Can you please elaborate about memory access procedure from TEE
A: Answered in video
Q: Do you have interface for Kernel driver to access this FW?
A: We have and it is currently kept out of tree. The intention is to upstream that also later on. See this commit: https://github.com/linaro-swg/linux/commit/860c46087c99c24073cc722b12c0017bb0ce0a79
Q: How much of GP test suite testing depends on HW?
A: We don’t think there is any dependency to hardware. It is all about software.
Q: Is a hardened/trusted Linux OS supported? TZAPIs? Container framework? What exactly is supported?
A: If you enable SELinux and other similar security enhancements, TrustZone will still work as long as you configure SELinux etc correctly (access permissions etc). TZAPIs? Those are the ones talked about in the video. There are APIs from user space normal world, in Linux kernel and from Trusted Application point of view. To answer what exactly is supported would give a long answer. But a very short summary: Secure storage, secure time, cryptographic operations for all the standard crypto,and big number to name a few
Q: Does OP-TEE feature a Secure File System?
A: Yes, secure storage as defined by GlobalPlatform has been implemented. More details about it can be found here: https://optee.readthedocs.io/architecture/secure_storage.html and here https://optee.readthedocs.io/architecture/secure_storage.html
Q: Do you support SMP?
A: Yes, we don’t make any difference between single CPU and multiple CPU (multi core) solutions. TEE / OP-TEE runs on all cores available. Which core it runs on depends on the core that was in use when user space / Linux do the SMC call.
Q: How is multicore handled in the communication driver? E.g. are CA/TA sessions tagged by a core ID affinity?
A: Answered in the video.
Q: Is OP-TEE Multi-threaded?
A: OP-TEE OS is multithreaded, Trusted Application’s in OP-TEE can not spawn multiple threads. I.e. Trusted Applications run in a single (OP-TEE OS) thread.
Q: Is there any TEE which supports multi-thread for TA?
A: Answered in video. The true answer is that we don’t know. OP-TEE does not support running threads in a TA context. But the OS itself on secure side has multithreading support.
Q: If i have to do a AES encryption (using the TEE services), is there some example of how to use the INVOKE IOCTL, or generally are existing applications available (I remember xtests having some demo cases)
A: Partly answered in the video, repeating here. xtest has quite a few tests where AES is being used. Having that said, xtest can be a bit hard to follow. Our suggestion is to instead take the Hello World Trusted Application (https://github.com/linaro-swg/hello_world) and try to do a clean AES operation from there according to the GP Client API (for the host application) and GP Internal Core API for the Trusted Application. If you try it out but cannot get it to work, please ask a question at https://github.com/OP-TEE/optee_os/issues.
Q: Also in v4.12, we see a staging driver of ARM’s CryptoCell driver, https://www.spinics.net/lists/linux-crypto/msg25437.html May I know your opinion about that. Are CryptoCell and OP-TEE related? How?
A: Answered in the video. But currently there is no official support for CrypoCell in OP-TEE. We have talked to ARM about it and related to that we have talked about adding official support for mBedTLS in OP-TEE. With support for mBedTLS there is a good ground for running CryptoCell also. Exactly when this will happen we cannot say. But we imagine that LibTomCrypt and mBedTLS will live side by side for a couple of months and when we are confortable with using mBedTLS we will eventually make a switch of default crypto library in OP-TEE.
Q: How about TA to TA communication? Is it supported?
A: Answered in video. It is supported.
Q: Currently is there any work on Trusted User Interface support?
A: Answered in video. Summary: Proof of concept was implemented a while ago and was tested in FVP and QEMU. There we can spawn a virtual keyboard which can be used to type user credentials etc. So, from secure side point of view, there is actually quite a lot of code for this. The major challenge here is to make it work together with Linux kernel and since we want to upstream everything we must come into agreement with the people working with graphics, rendering, framebuffers etc in Linux kernel and there we haven’t done much work yet. Mainly just discussions with some kernel developers. Eventually we will start by doing an out of tree proof of concept here also, but that will most likely be something that cannot be submitted upstream as it is.
Q: What is the future roadmap for the Linux TEE/OP-TEE infrastructure? What about support for client apps in containers and/or virtualization?
A: Answered in video, but to give some additional information, we have lots of areas we would like to do more work in. Benchmark framework for TEE(s). Trusted UI, implement a Secure Domain concept, add support for signing TA’s with different keys, IMA, OTrP, PCSI library on ARM V7-A etc etc. We intend to make some kind of public roadmap available so people will have a better understanding of what will happen and what to expect.
Q: I am interested in hearing what is supported by secure user space, not familiar with this area of the OP-TEE framework.
A: Look at the GlobalPlatform Internal Core API specification. We have full support for that in OP-TEE (https://www.globalplatform.org/specificationsdevice.asp)
Q: ACPI is preferred over device trees for enterprise class systems. Are there plans to make the TEE driver ACPI enabled?
A: No plans right now, however having that said isn’t the same as saying that it will never happen. It is just that our partners haven;t been asking about it and therefore it hasn’t got our attention. If people need this and bring it to our attention, then it will probably get higher priority.
Q: Does Linaro provide training in addition to the Github documentation, like instructor led classes or consulting services?
A: In Linaro we have professional services, which can help with training and consulting. For more information about that, please have a look here: https://www.linaro.org/professional-services/
Q: How fast in terms of context switching is this TEE framework compared with existing proprietary solutions ?
A: We have no numbers from proprietary solutions, but the switch itself (the SMC) is fast. At Linaro Connect in Budapest, ARM told us that we are talking about nano seconds and that is the same for any TEE solution. The difference depends on where you make you measurements, but the context switch is done right before/after the SMC call in OP-TEE, so that shouldn’t add too much overhead. Related to this we have worked with implementing the basis for a benchmark framework. First set of patches for that has just been merged and our intention is to give more true answers to questions like this. So we hope that we can give precise numbers rather soon.
Q: Do you see any specific automotive use cases for OP-TEE?
A: Automotive Grade Linux are already using OP-TEE in some projects, see this presentation for example: https://www.slideshare.net/YannickGicquel/introduction-to-optee-26-may-2016. But without knowing too much about the use cases I would imagine that infotainment in cars (including DRM protected video), secure boot and authentication are use cases that are being implemented.
Q: What is a recommended way of calling a secure service from a Linux instance running in KVM?
A: We haven’t done much work in the virtualized area, but there is one engineer that is quite active in OP-TEE work that has started to look into this, you can find out more about the work he has been doing and the open questions here: https://github.com/OP-TEE/optee_os/issues/1019. The question is whether to trap HVC or SMC and how to separate memory etc from different VMs.
And that’s it! All these questions were from one webinar session. Thanks to all those who joined and especially those who pitched in with some tricky questions to make us sweat. Once again, the webinar and slide deck are here:
For further information please see the OP-TEE and Linaro websites.
Details of OP-TEE mailing lists and bug reporting are at https://optee.readthedocs.io/general/about.html
For general questions to Linaro about membership and professional services such as training and consultancy, please see https://www.linaro.org/contact/