Arm TrustZone was introduced to the Arm architecture A-profile in 2003. At the heart of the TrustZone approach is the concept of Secure and Normal worlds that are hardware separated. Secure hardware resources are only accessible by the software running in the Secure world. Software in the Normal world is blocked by the hardware from accessing these resources. This concept of Secure (trusted) and Normal (non-trusted) worlds extends beyond the processor, to encompass memory, software, bus transactions, interrupts and peripherals within a System on a Chip (SoC).
The introduction of TrustZone has paved the way for an ecosystem of trusted operating systems (OS) vendors. Initially, trusted OSs provided basic device security services, such as trusted boot, or handling of platform secrets. Today, trusted OSs have evolved to support bespoke applications that might be used in a variety of security use cases, such as secure payment or media protection.
Originally, trusted OSs occupied all processor modes associated with TrustZone, and included code devoted to switching between the Normal and Secure worlds, as well as code for providing secure services. In systems based on Armv7, and prior architecture revisions, the switching code runs in monitor mode, whereas services code runs in secure supervisor and secure user modes. In Armv8, monitor mode evolved into an exception level, EL3, with its own memory translation regime and interrupt vectors. This allowed for cleaner separation of code, making it easier to provide separate binary images for switching, and for services.
The advent of EL3 provided new opportunities to standardize key platform management functions. Until then, these were implemented in Normal world software, leading to fragmentation, and solutions that had to be repeated for each OS and each individual platform. The addition of an exception level has made it possible to provide standard firmware solutions for these management functions, removing the fragmentation and generalizing code in Normal world operating systems. An example of this is the Power State Coordination Interface (PSCI) which is a widely adopted standard for system and processor power management. This standardization momentum doesn't stop at specifications and includes the Trusted Firmware open source project, formerly known as the Arm Trusted Firmware project.
The success of TrustZone has also created some architectural challenges. In particular, the Secure world now has software from multiple vendors. More than one trusted OS might be required, as applications tend to be specific to each trusted OS. Additionally, platform firmware will be required, and can come from a silicon vendor or an OEM or both. Finally, most implementations carry code from the Trusted Firmware open source project. At the same time, in architecture revisions prior to Armv8.4, there is no mechanism to isolate payloads running in Secure EL1 from the rest of the system. This makes it very hard to isolate code from the various vendors. These factors conspire to make it difficult and costly to audit Secure world code.
To address these challenges in Armv8.4, we have introduced Secure EL2, which provides mechanisms to isolate secure payloads from each other, and from the Normal world. Leveraging this technology requires new thinking in security software architecture for A-profile processors.
In our latest whitepaper, Isolation using virtualization in the Secure world, Charles García-Tobin, OS architect and Arm Fellow, discusses Secure EL2 and its ramifications for software architecture.
[CTAToken URL = "https://developer.arm.com/products/architecture/security-architectures" target="_blank" text="Download whitepaper" class ="green"]
Please send your feedback to arm.s-el2-feedback@arm.com