Generic TrustZone Driver


Today, TrustZone solutions are implementation specific. In user space, mobile devices are normally compliant with Global Platform’s API. However, there is no common TrustZone interface for kernel space, as it exists for Trusted Computing Module (TPM). As a result, different TrustZone frameworks use different kernel loadable modules to provide the context to communicate with the Trusted Execution Environment (TEE) leveraged by TrustZone’s secure world.

Regarding use cases, TrustZone has traditionally been used for offloading secure tasks to the secure world. Examples include banking applications, Digital Rights Management (DRM), or specific secure solutions. As more and more frameworks enabling TrustZone appear, new use cases are starting to emerge: key management, encryption, integrity checking, etc. Extreme cases today involve running a RTOS in the secure world, or using the secure world to implement usage control policies governing the normal world. The advent of ARMv8 will only expand this list.

In the context of my Ph.D (link soon), I proposed the first generic driver for TrustZone enabled devices for Linux systems. I submitted a set of patches implementing it to the Linux Kernel Mailing List (LKML) (link). This has been the first attempt to implement TrustZone support in the Linux kernel. Since then, I have worked with Linaro in resubmitting the driver applying the feddback we obtained from the kernel community. This new version of the driver targets Trusted Execution Environments instead of TrustZone specifically. The reason is that new non-TrustZone specific technologies are emerging that can provide a TEE. This aligns with the primary objective of providing a generic solution. Still, since TrustZone is still one if the most popular TEEs, TrustZone support is as for today the focus of the project. A first RFC patchet has already been submitted to the LKML by Jens Wiklander (here).

Development is taking place in GitHub (here).

Design and implementation details of the driver ar being discussed on tee-dev<at> (archive here)