Sunday 8 May 2016

[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/

No comments:

Post a Comment