Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

TrustZone, Jacob Beningo, embedded, ESC, Embedded Systems Conference, ARM

Digging Deeper into TrustZone for ARMv8-M

TrustZone is the tool that developers can use to improve their system security. But only through proper use will any system become more secure.

In my recent post, “An Introduction to the ARMv8-M Architecture,” we started to examine the new ARMv8-M architecture that includes the Cortex-M23, Cortex-M33, and Cortex-M35P processors. We saw that these processors include an optional security extension known as TrustZone, which is new to the ARM Cortex-M processors. In this article, we’ll begin to examine TrustZone and how embedded software developers can use it to improve their systems' security.

TrustZone is designed to help the embedded systems developers working on resource constrained devices improve their security architecture. It provides developers with a way to containerize and isolate their software while still providing characteristics expected on a Cortex-M processor like low interrupt latency. TrustZone breaks up the memory, processing domain, and application into two separate domains—Secure and Non-Secure, which are also sometimes called trusted and user applications, respectively.

A TrustZone application starts executing in the firmware project from a secure state and then jumps to the user project to run the user application. At this point, the application execution will run in the non-secure or secure state based on the code that is executing. (Image source: ARM)

The user domain contains items such as user applications, a RTOS, device drivers, protocol stacks, and general peripherals. The user domain behaves exactly as today’s typical Cortex-M application. In fact, a developer could use a TrustZone processor with TrustZone disabled and they would not notice any difference. That would defeat the whole purpose, though. The secure domain contains several items that are designed to secure the system, such as secure boot, secure storage, cryptographic libraries, and even RTOS tasks and kernel code. These items certainly exist in today’s user applications. But with TrustZone, they now have the ability to exist in a state where they are no longer directly accessible without explicitly doing so.

Developers working with TrustZone for the first time will discover that even the way the software is developed is different. Instead of using a single code project, developers will now need to break their application up into two separate applications: the firmware project and the user project. The firmware project contains all the secure code for the application and will reside in the secure memory locations. These memory locations are not accessible to the outside world or the user application unless a developer specifically creates a secure gateway in their code to expose a secure function. It’s important to be aware, though, that the secure region has complete access to all memory locations. This means that software written for the secure domain needs to be very careful if it plans to access data or firmware in the less secure user application space.

The user application is standard and is the type that every Cortex-M developer is used to by now. As mentioned previously, the user application is limited as to which memory locations, functions, and peripherals it can access. If a secure function needs to be executed, the user application can make a call to the secure domain through a secure gateway. If the user application attempts to access any other secure memory area, a fault will result. This prevents an errant user program from randomly accessing secure memory or manipulating it in any way.

TrustZone applications start out by executing in the secure domain. Developers start with their secure boot application and can bring up their processor. Once this is done, the execution can switch from the secure state to the user state and begin executing the user code. An example can be seen in the figure below.

When the processor switches from the user state to the secure state, hardware handles the transition and the developer doesn’t need to add code. Instead, a CPU instruction is automatically added by the compiler, indicating the switch into the secure state. The worst case deterministic overhead to switch between the two states is three clock cycles. Depending on the application, the overhead could be larger if the developer is making a function call and needs to verify function parameters or test a pointer that is being passed between the domains.

As developers first encounter TrustZone for the Cortex-M, they’ll discover that the way in which they write their applications will be forever changed. They will literally have to set up two applications, where one will exist in a user domain and the other in a secure domain. Having to develop software differently isn’t necessarily a bad thing when the opportunity exists to improve the system's security. Developers will need to carefully think through their applications' architecture and make sure they properly identify the domain in which their software and data should exist. TrustZone is the tool that developers can use to improve their systems' security. But only through proper use will any system become more secure. 

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost, and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees, which include a Masters of Engineering from the University of Michigan. Feel free to contact him at, at his website, and sign-up for his monthly Embedded Bytes Newsletter.

ESC, Embedded Systems ConferenceToday's Insights. Tomorrow's Technologies.
ESC returns to Minneapolis, Oct. 31-Nov. 1, 2018, with a fresh, in-depth, two-day educational program designed specifically for the needs of today's embedded systems professionals. With four comprehensive tracks, new technical tutorials, and a host of top engineering talent on stage, you'll get the specialized training you need to create competitive embedded products. Get hands-on in the classroom and speak directly to the engineers and developers who can help you work faster, cheaper, and smarter. Click here to register today!
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.