5 Secure Execution Environment

Establishing a root of trust on the device generally requires the creation of a secure execution environment, sometimes also referred to as a trusted execution environment (TEE). The essential idea behind secure execution environments is to create separate code execution domains, or “worlds”, that have different privileges and access rights to system resources. Secure execution environments can protect code and data in use from unauthorized modification, extraction, or tampering by malicious software or hardware. A hardware security module (HSM) is a typical example of a secure execution environment that is purpose-built for providing cryptographic services, secure storage, root of trust, and authentication for a host microcontroller or processor. TI’s AM26x and F29x microcontrollers include an available built-in HSM with these features, enabling a secure key and code provisioning process, secure boot, debug authentication and cryptographic services for the application.

In many cases, establishing a root of trust alone is not sufficient, as modern applications must deal with potential cybersecurity threats in a connected environment. External communication interfaces, such as a CAN bus or UART port, can potentially be vulnerable to exploits that end up compromising the integrity of the software tasks that operate these interfaces. Given the unpredictable nature of these threats, a complete cybersecurity threat assessment will necessarily include the presumption of compromised code modules, and the risk they pose to the confidentiality, integrity, availability and safety of the whole system. Run-time application security is therefore an important aspect of cybersecurity implementation in embedded systems.

Software-based measures for run-time security are undesirable in real-time control systems, due to the additional processing burden required, which typically means added latency and reduced overall control loop performance. In addition, software-based solutions are not immutable; compromised code could lead to a defeat of the entire run-time security apparatus. A hardware-based solution typically starts with some type of memory protection unit, or MPU. MPUs allow the application developer to define fixed memory regions, and configure access permissions (read, write and execute) for each region depending on the initiator attempting to access it. These initiators can include CPUs, DMAs and debuggers. In the TI F29x family of microcontrollers, memory and peripheral access protections are context-sensitive. The application can be divided into multiple code modules, based on the address range each application code module resides in. Any range of data or peripherals belonging to a code module can then be shared with other code modules, with individual read or write permissions defined. Because these hardware memory protections are specific to the code module performing the access, the need for a software OS layer managing the MPU is eliminated, thus maintaining code and data safety without compromising performance.

In addition to memory access protection, the security of data inside the CPU is also critical to establishing a secure execution environment. An intruder could snoop on the CPU as it executes code, reading out secrets from CPU registers and shared stack memory. One approach to dealing with this issue is software-based: a task scheduler in the operating system layer is responsible for isolating different application tasks or threads from each other. The OS maintains thread context by saving, clearing, and restoring registers when switching to a new task. The main drawback to this approach is that interrupt service routines, which are key to real-time processing applications, cannot be directly isolated using a task scheduler. Hardware features that help isolate application contexts within the CPU are therefore key to achieving run-time security in an embedded real-time system. Often this involves hardware handling of stack pointers, with a division between “secure” and “non-secure” worlds, or in CPU architectures such as C29x, multiple fully isolated stacks. Typically, this type of CPU instruction set includes gate instructions that are required to cross stack boundaries. The gate instruction can trigger processes such as register zeroing, and an associated access protection scheme that specifies what memories can be written or read. In architectures such as Arm® TrustZone®-M, a trampoline or veneer function is generally required to handle these protection changes during the transition from one context to another.

Texas Instruments C29x, on the other hand, mostly handles context switches in hardware, applying new protections in real time to maximize control performance.

With hardware-enabled protections for code and data in the CPU, the embedded system designer can partition the application into security sandboxes and application task modules, each with its own private code, data, and peripherals. Each of these task modules can also optionally share memory regions with other tasks. An example security partitioning scheme is shown in Figure 5-1. Often a real-time operating system layer is required to implement such schemes, but with isolated stacks and context-aware memory access protection in hardware, system designers can achieve complete isolation while avoiding the extra latency that comes with a software OS layer.