Trusted Execution Environment on seL4 [Update 1]

The coding period for this year's Google Summer Of Code started earlier this week and I take this as an opportunity to write about my plan for the project and report on the progress so far. As I had written in my earlier blog post , the key to building a TEE for RISC-V lies in the seL4 port for it. So my approach will involve building a TEE on top of seL4. Instead of going for para-virtualized solutions of porting OPTEE-OS I have decided to implement the features of OPTEE as a library for seL4 and build a TEE which for the most parts can be architecture independent.



Architecture diagram:



seL4 layer: This is the standard implementation of seL4 ,for now I have been using ia32 implementation but I could switch to the RISC-V one once it is stable.

virtualized RICH-OS: A virtualized OS like Linux or Android on top of a VMM. It will have a client library and have drivers to communicate with the TEE-container.

TEE container: The TEE container is similar to OPTEE-OS it will house the Trusted applications and allow communication between the RICH-OS and the TA.

TA: Trusted applications will be spawned as processes from the TEE-container and the library will be similar to OPTEE's tee_internal_api . There will be a format which a TA has to follow quite similar to OPTEE's format.

To be certified by Global Platform a TEE should provide the following services.

• Trusted Storage API for data and keys
• Time API services
• Cryptographic operations
• Arithmetic API

Another feature which is essential in a TEE is secure boot. I need to implement a secure boot features which guarantees booting into the Trusted-OS by a chain of trust.


Progress so far:
The github repository for the project: https://github.com/hybridNeo/sel4-tee-os
and for the sample app : https://github.com/hybridNeo/sel4-tee-os-sample-app

I have built a proof of concept TEE-container and a sample app quite similar to the LCU14 OPTEE Hello World demo https://github.com/jenswi-linaro/lcu14_optee_hello_world

For now the TEE-container boots up and is able to start Trusted applications, it is also able to call functions on the TA.
The internal api for the TA allows for a function handler to be defined to handle function calls just like in OPTEE.
The sample TA has a function which increments the input parameter just like LCU14 OPTEE demo.

Writing the TA is quite similar to the process followed for OPTEE.

Next weeks plan:

1. Support multiple TA's
2. Each TA should have memory isolation.
3. Look at implementing some services if time permits.

I will most likely make this blog weekly, please feel free to share your opinions and questions on this project.

[GSOC 2016 ] Implementing a Trusted Execution Environment for RISC-V architecture

I am happy to announce that I will be participating in the 2016 edition of the Google Summer Of Code with lowRISC[1] ,an organization which aim's to create a fully open source Linux capable RISC-V[2] based SoC. I will be mentored by Stefan Wallentowitz and also co-mentored by Hesham Almatary.

RISC-V is an open source instruction set architecture (ISA) which allows anybody to design, manufacture and sell chips. It was originated in 2010 in the Computer Science division of UC Berkeley.

A Trusted Execution Environment(TEE) allows for isolated execution of code and provides integrity of trusted applications and their assets. ARM has been a pioneer in this field and OPTEE is one such open source solution for the same. Having worked with OPTEE for a good portion of the last six months made me realize the importance of a TEE for any architecture.

I will be looking at OPTEE as a reference and trying to port it to RISC-V. While coming up with the proposal with Stefan, there were three methods to port which were put forward.

1. Direct port of OPTEE: In this method the entire OPTEE-OS code base would have to be ported to RISC-V and we would have to have a software layer that emulates ARM-TrustZone layer . This method would be on the more complex side, I have gone through the code base and have identified parts of OPTEE-OS and libraries which are architecture independent.

link: https://docs.google.com/document/d/1lTZs8_2h1yRyWLGcc2QwPAeDXTQObOrJMBo_um5sNfk

2. Running OPTEE on top of seL4 by paravirtualization :
Hesham Almatery has successfully ported seL4 for RISC-V as a part of last year's GSOC , So I could use that.

• Here seL4 works as a hypervisor.
• The TrustZone features and secure monitor must be implemented as a seL4 library.
• OPTEE is paravirtualized, all calls referencing ARM TF and secure monitor are replaced with new calls.
• I still do not know how virtualization works in seL4, setting up hypervisor(vmm). This is something I have to figure out before the coding period starts.

3.Use seL4 as the Trusted OS: If I go for this approach , libraries will be built for seL4 for it to be used as a secure world OS(TEE).

1. Secure monitor could be built using seL4 IPC mechanism.
2. The normal world OS will be virtualized on top of seL4.
3. Secure boot is readily available for seL4
4. This approach is potentially portable to any platform.
5. seL4 is the secure OS hence we will have to implement secure
storage as well as crypto API’s as seL4 services.
6. A trusted application could be like containers inside seL4.
7. library for crypto libucrypt are architecture independant for the most part hence can be used directly.

It is likely that I will choose to go for the second or third approach as the first approach seems very complex.


References:
[1] - http://www.lowrisc.org/
[2] - http://riscv.org/