A technical report on TEE and ARM TrustZone

In this article, I will give an introduction of TEE (trusted execution environment) and ARM TrustZone based on my one and a half year experimentation on several ARM platforms when implementing T6.

What is TEE?

To begin with, let’s first identify the slight difference between the word Trusted and Trustworthy. Trusted means someone or something you rely upon to not compromise your security while Trustworthy means someone or something will not compromise your security. Or in other words you could treat Trusted as how you use something while Trustworthy is about whether it is safe to use something. So Trusted Execution Environments are what you may choose to rely upon to execute sensitive tasks and of course hopefully they are trustworthy too! Generally speaking, there are five security properties that TEE may want to achieve:

• Isolated Execution
• Secure Storage
• Remote Attestation
• Secure Provisioning
• Trusted Path

What kinds of TEEs are now available?

Nowadays, there are several TEE platforms available for both research community and industry, including:

• TPM (Trusted Platform Module). TPM is a dedicated microprocessor designed to secure hardware by integrating cryptographic keys into devices and is available in many modern computers. To utilize the secure primitives of TPM, applications usually combine the TPM (hardware) and the TXT (software) to provide a strong isolation. One thing needs to be pointed out is that, TPM is really SLOW, vendors does not have any motivations to keep it faster, they just make sure it works with low cost!
• Intel’s TXT (Trusted Execution Technology) or AMD’s SVM (Secure Virtual Machine). To use the TXT, there are several steps:
  • 1. Suspend OS
  • 2. Execute small amount of code (trusted code) on main CPU
  • 3. Restore OS.
  • While these three steps seem to be simple, actually there is no commercial applications using these technology with several reasons: firstly, when the TXT is on, only one CPU is allowed to execute even in a multicore  machine while other cores are suspended; secondly, there is no interrupt and IO operation in TXT and to keep the TCB as small as possible,  no OS libs are available, that means, you need to take huge efforts in order to run rich functionality applications.
• Hypervisor-based TEE. Virtualization is a straightforward method to implement TEE and there are large number of systems using hypervisor based solution to provide TEE like functionalities.
• ARM TrustZone. ARM TrustZone is thought to be the most promising technology to implement TEE in mobile devices (or ARM devices).

What is ARM TrustZone?

ARM TrustZone technology aimed at establishing trust in ARM-based platforms. In contrast to TPMs, which were designed as fixed-function devices with a predefined feature set, TrustZone represented a much more flexible approach by leveraging the CPU as a freely programmable trusted platform module. To do that, ARM introduced a special CPU mode called “secure mode” in addition to the regular normal mode, thereby establishing the notions of a “secure world” and a “normal world”. The distinction between both worlds is completely orthogonal to the normal ring protection between user-level and kernel-level code and hidden from the operating system running in the normal world.

Furthermore, it is not limited to the CPU but propagated over the system bus to peripheral devices and memory controllers. This way, such an ARM-based platform effectively becomes a kind of split personality. When secure mode is active, the software running on the CPU has a different view on the whole system than software running in non-secure mode. This way, system functions, in particular security functions and cryptographic credentials, can be hidden from the normal world. It goes without saying that this concept is vastly more flexible than TPM chips because the functionality of the secure world is defined by system software instead of being hard-wired.

Details of ARM TrustZone

The TrustZone hardware architecture includes the SoC and peripherals that are connected with the SoC. The SoC includes a core processor, Direct Memory Access (DMA), secure RAM, secure boot ROM, Generic Interrupt Controller(GIC), TrustZone Address Space Controller (TZASC), TrustZone Protection Controller, Dynamic Memory Controller(DMC) and DRAM, they communicate with each other through AXI bus. The SoC communicates with peripherals by using the AXI-to-APB bridge.

TrustZone Hardware

Split-World-based Isolated Execution

A physical core processor with TrustZone support works safely and efficiently in two worlds: normal world (or non-secure world) and secure world. CPU states is banked between two worlds and by default the secure world can access all states of normal world but not vice-versa. Below the two worlds, there is a higher privilege mode called TrustZone monitor mode that is usually used for switching between the two worlds either by executing the Secure Monitor Call (SMC) instruction or external interrupts and is responsible for banking the CPU state.

Memory and Peripheral Protection

TrustZone supports memory partition between two worlds by using TZASC and TZPC. TZASC can partition DRAM into several memory regions, each of which can be configured to be used be in normal world or secure world or a more dynamic and complicated access permission control. By default, secure world applications could access normal world memory but not vice-versa. However, by enabling security inversion in TZASC, one normal world memory could also be configured as normal world accesses only.

TZPC is mainly used to configure peripherals as secure or non-secure and the world sensitive AXI-to-APB bridge will deny illegal access to the protected peripherals. Besides above, on-SoC static memory like ROM or SRAM also need to be protected. This is done by a SoC peripheral called TrustZone Memory Adapter (TZMA), though no direct software configuration registers are provided by TZMA. Usually internal ROM is set as secure by hardware design and the partition of secure and non-secure region in SRAM is configured by setting the R0SIZE register in TZPC. Both TZASC and TZPC can be accessed and configured only in secure world. A security access violation may cause an external abort and trap to either monitor mode or current CPU state mode exception vector, depending on the configuration of the interrupt behaviour in monitor mode.

Besides the physical memory partition, a TrustZone-aware MMU enables both worlds with distinct translation tables and with a tag in TLB to identify the world to avoid flushing TLB when switching world. For Direct Memory Access (DMA), there is a multi-channel system controller called Direct Memory Access Controller (DMAC) that moves data around the physical memory system. DMAC is world sensitive and support concurrent secure and non-secure channels. A normal world DMA tranfer data to or from secure memory will be denied, thus avoiding security hole.

Interrupt Isolation

There are two kinds of interrupts: IRQ(normal interrupt request) and FIQ(fast interrupt request). GIC with Trust- Zone support can configure an interrupt as secure or non-secure. Usually IRQ is configured as normal world source and FIQ as secure world source, because IRQ is themost common interrupt source in use in modern operating systems. When executing in secure world, a secure interrupt will be handled by secure world interrupt handler; when a non-secure interrupt occurs during secure world execution, the interrupt will be transfered to monitor mode interrupt handler and the software handler can decide whether drops the interrupt or switches to normal world. The configuration of GIC that is security related can only be configured in secure world, thus preventing illegal modification from normal world. The secure configuration register(SCR), which is in the control coprocessor CP15 and is accessible in secure privileged mode only, could be programmed as trapping external abort(i.e.memory access permission violation), IRQ or FIQ into monitor mode or handling the interrupt locally in the current world.

Could ARM TrustZone be used to implement or replace virtualization?

As many researchers proposed, ARM TrustZone can be viewed from two angles, as virtualization solution and as mechanism to implement functionality similar to Trusted Platform Modules (TPM). When regarded as a virtualization solution, TrustZone is severely lacking:

1. The number of virtual machines is limited to two, one running in the secure world and one running in the non-secure world.
2. The  trap-and-execute model for emulating devices is not possible because security violation abort is always asynchronous.

So to support devices emulation, certain device drivers of the non-secure OS must be modified and thus running OSes like Windows is not possible (which only binaries are available). I dare to say that perceiving TrustZone as a virtualization mechanism is not a good choice! When looking at TrustZone as an alternative for TPMs, the motivation behind this technology become much more clear. In contrast to fixed-function TPMs, TrustZone is a vastly more versatile mechanism with unlimited resources and fast chips.

Could ARM TrustZone be used as TPM directly? Does ARM TrustZone provide secure key storage?

I am afraid not. The problem is the lack of secure storage, as the TrustZone specification doesn’t provide any mechanism to implement secure storage. However, the TrustZone feature: assigning a specific peripheral to secure world access only is the key point, but it is up to the SoC vendors or the TEE developers to decide what peripheral is used as a secure storage media.

[CTAToken URL = "https://developer.arm.com/technologies/trustzone" target="_blank" text="Learn more about Arm TrustZone" class ="green"]