OP-TEE (Open Trusted Execution Environment) is a open-source project which aims to implement a complete Secure Operating System to run inside ARM TrustZone-enabled Secure World and facilitate the development of Trusted Applications (TAs).

OP-TEE's main components are:

• A secure kernel (OP-TEE OS), executing in EL1 privileged mode;
• A set of secure libraries (mainly for cryptographic needs) and scripts to ease the development of Trusted Applications (TA);
• Linux (Normal World) libraries for exchanging messages with a TA;
• Linux kernel TEE driver (mainline) to communicate with the Secure World using shared memory pages;
• A Linux TEE supplicant daemon to provide Rich OS services to the TAs (e.g., network / filesystem access).

The OP-TEE kernel resides in the ARM TrustZone Secure World's Exception Level 1 (same place as the Non-Secure Kernel, but different trust domain) and gets loaded early in the boot process (BL32), just before the normal bootloader + Linux OS. The Trusted OS provides a minimal set of services (e.g., cryptographic routines, secure memory management) and drivers (for interfacing with the secure hardware) for the Trusted Applications, as well as a mechanism for calling untrusted functions from the Rich OS (i.e., Linux) in order to limit its complexity as per the aforementioned security recommendations.

Note that BL31 (the ARM Trusted Firmware-A, in most cases) is reponsible for initializing the TrustZone hardware isolation (especially the TZASC memory regions, interrupt controller etc.). The Secure Monitor (EL3) implementation is also part of TF-A and NOT OP-TEE, though it has a module specific for integration with the latter.

OP-TEE also provides a software framework for developing Trusted Applications. Recall that such applications have two parts: an untrusted Host Application running inside Normal World (under the Linux kernel) and the proper TA executing inside the isolated context. The SDK covers both components and provides an API (as C functions) for facilitating the communication between them (which we'll briefly use a the lab).

Again, we point to the fact that a Secure Kernel does not implement several features which, nowadays, we take for granted, such as: networking (TCP/IP stack), file system access (and, in fact, most kinds of external disk I/O), graphical devices (i.e., GPUs), multi-threading etc. – since all of those sum up to millions of lines of code, defeating the assumptions of the secure architecture for being its components being small and easy to verify for correctness. Nevertheless, we can import and readily use these functions from the Normal OS via proxying (system calls are forwarded by the Secure Monitor through the Worlds barrier, executed on the untrusted realm and the results transported back to the secure application). A word of warning, though: such functionality must be regarded as insecure and all data must be protected (encrypted) and validated (authenticated) beforehand.