Friday, 27 May 2016

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:
and for the sample app :

I have built a proof of concept TEE-container and a sample app quite similar to the LCU14 OPTEE Hello World demo

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.

1 comment: