 Hello and welcome to this presentation of the TrusZone security concept implemented on top of the ARM V8M architecture compliant Cortex-M33 core. This presentation applies to an STM32L5 where the TrusZone feature has been activated by setting the non-volatile option bit TZEN to 1. TZEN can only be set when readout protection level is 0. The ARM V8M architecture implements TrusZone for Cortex-M cores. As explained in the figure, the V7M cores support one kernel running in privileged state, switching on privileged stacks. When the security features of the core are enabled, there are two orthogonal security states, secure and non-secure. The non-secure kernel and applications run in non-secure state while the secure kernel and applications run in secure state. The security state of the processor depends on the address at which the instruction was fetched. The processor always resets to secure state when the TrusZone feature is enabled. Each security state supports both privileged and unprivileged user access. When the TrusZone feature is not enabled, the programmer's model only includes the non-secure state. For each security state, the processor can operate in thread or handler mode. At reset or on a return from an exception, the processor enters thread mode, both privileged and unprivileged states can run in thread mode. The TrusZone feature is optional on ARM V8M core. When not enabled, the SCM32L5 microcontrollers, embedding the Cortex-M33 V8M compliant core, run in non-secure state which is identical to the ARM V7M core execution environment. When enabled, the microcontroller boots in secure state and during runtime can transition back and forth from secure to non-secure. As for TrusZone in Cortex-A processors, code running in secure state can access both secure and non-secure data. Non-secure data accessed by secured software is tagged as non-secure to pass downstream firewalls. TrusZone for Cortex-A is based on a secure monitor which is in charge of switching the two secure worlds, so transitions are requested through software exception taking and returning. TrusZone for Cortex-M is based on memory mapping, enabling direct access to the secure world by using function calls and returns, thus optimizing switching overhead. TrusZone for ARM V8M and ARM V8A have the same objectives, supporting secure and non-secure partitions running on the same core and ensuring the protection of secure resources. However, the operations of TrusZone for ARM V8M are very different as they are optimized for embedded systems that requires real-time responsiveness. Function calls and returns are used to perform the switch between the two security worlds instead of exception taking and returning. This slide describes the memory mapping used when the core runs in non-secure state. It's identical to the ARM V8M memory mapping. Branches to memory locations defined by secure software and called secure gates enable non-secure software to call a secure service. Secure memory is invisible from non-secure software. This slide describes the memory mapping used when the core runs in secure state. Secure memory view shows additional secure flash, RAM and peripherals address ranges. Access to all regions is possible in secure state. Since resources such as System Control Block or SCB, Memory Protection Unit or MPU and C-Stick Timer are duplicated, one instance being secure, the other non-secure, the non-secure instances are shifted in the memory mapping by an offset equal to 0x20000. Secure software can therefore access secure and non-secure instances of these units. Privileged secure software assigns the security to memory regions by programming the Secure Attribution Unit or SAU. Two units determine the security attribute of memory regions, the Security Attribution Unit or SAU which is programmable, the Implementation Defined Attribution Unit or IDAU which is hard-coded. When SAU and IDAU provide different setting for the security attribute, the most conservative one is selected. For example, if SAU maps a region as non-secure and IDAU as secure, the region is tagged as secure. SAU supports eight regions defined by start and end addresses. The alignment requirement for start and end address is 32 bytes. The V8M Memory Protection Unit or MPU is also programmed through start address and end address. The V7M MPU is based on start address and power of two size. Therefore, these two versions of the MPU are not compatible. MPU is banked for secure and non-secure worlds. The STM32L5 supports 16 regions per MPU. The processor state depends on the memory space definition. When the processor is running code in a secure region, it's in secure state. Otherwise, it's in non-secure state. Intersecurity domain calls and returns are supported. The processor detects the security domain of the branch address and switches domain automatically. The ARM V8M defines the following security attributes. Secure region which contains secure program and data. Non-secure callable region which is secure but can be called from non-secure state. Non-secure region which contains non-secure program and data. The non-secure callable region enables non-secure software to call a secure service. It's declared by secure software and must contain a secure gateway or SG instruction to cause the transition to secure state. The IDAU is external to the ARM core. Through an address decoding logic it returns to the core the security attribute of the region as well as its number. It can also mark a region to be exempted from security checking such as debug units. The core site specification which is a framework for debugging ARM cores implements another mechanism to assign security attributes to debug units based on authentication signals sampled by these units. The secure attribute delivered by the SAU and IDAU can be secure, secure non-secure callable and non-secure. The slide represents the switch from non-secure state to secure state when it's triggered by a non-secure application. When the non-secure application requests a secure service it first calls a veneer contained in the secure non-secure callable region. This veneer must start with an SG instruction. If these conditions are satisfied then the transition to secure state is effective. The veneer generally branches to a secure region containing the library of secure services. Once the secure service is completed a direct transition from secure region back to non-secure region is performed. The protected memory system architecture described in ARM v7 M specifies an MPU whose region size is a power of two and region address is a multiple of its size. The protected memory system architecture described in ARM v8 M specifies a new MPU whose region's boundaries are defined by a start and end address pair. The alignment requirement for start and end addresses is 32 bytes. This is much more flexible as the kernel can directly program MPU regions from start and end addresses of the various sections to be mapped. The STM32L5 supports eight regions for the secure MPU and eight regions for the non-secure MPU. The example which is provided here compares the MPU region setting in PMSA v7 MPU and PMSA v8 MPU when the area to be mapped is 274 kilobyte long starting at hexadecimal address 0x3bc00. Due to the power of two size and alignment constraint four regions are required for PMSA v7. One unique region is required for PMSA v8. The ARM v8 M architecture provides new features regarding start pointers. In ARM v7 M two stack pointers are banked the main stack pointer or MSP and the process stack pointer or PSP. The ARM v8 M implements another level of banking between secure and non-secure states. Globally four stack pointers are present two pairs of MSP and PSP one per security level. Furthermore new stack limit registers enable hardware to detect stack overflow conditions. Both MSP and PSP stack being protected two pairs of stack limit registers are implemented one per security level. Non-secure PSP and MSP limit registers and secure PSP and MSP limit registers. Stack overflow detection generally requires the definition of one non-accessible region per processor stack in v7 M systems. The STM32L5 security attribution units have the following features. The fixed IDAU has a granularity of 64 megabytes and supports the following security attributes. Secure non-secure callable, non-secure and exempted regions. The programmable SAU supports eight regions featuring the following attributes non-secure or secure non-secure callable. Unmapped regions are secure by default. The resulting attribute when IDAU and SAU regions overlap is the most conservative one. For example in the figure here when the unmapped secure SAU region overlaps with the secure non-secure callable IDAU region the resulting attribute is secure. So for a region to be non-secure both IDAU and SAU attributes related to this region have to be non-secure. When an interrupt has the same security level as the current processor state then the exception sequence is almost identical to the v7 M processors. On this slide it corresponds to the transition from thread mode to handler mode which is handled identically in secure and non-secure states. When a non-secure interrupt occurs while the processor is running in secure state a transition from secure to non-secure state has to be performed avoiding any leakage in general purpose registers. This is achieved by automatically pushing all secure information onto the secure stack and raising the contents from the register banks. The consequence is an increase of the interrupt latency time from 12 o'clock to 21 o'clock. The slide represents all possible transitions between the four possible processor states. The aid transitions in the middle of the figure cause a change of the security state. Function calls and returns can be used when the privileged state remains the same for instance from non-secure thread mode to secure thread mode otherwise an interrupt entry and return is required. When trust zone is enabled non-secure exceptions are handled by non-secure kernel and secure exceptions are handled by secure kernel. Consequently two separate vector tables are implemented. The two first entries of the vector table are reset vectors respectively default main stack pointer register value and default program counter or PC register value. Unlike v7m calls such as cortex m4 the default location of the vector table is not necessarily at address zero since the processor boots in secure state the register pointing to the secure vector table called vtor s is initialized from core input signals sampled upon reset. Then the secure software can program the register pointing to the non-secure vector table called vtor ns and initialize the two first entries of the non-secure table mspns and pcns in order to emulate a non-secure reset. When trust zone is disabled a unique vector table is used because the core only runs in non-secure state. This slide describes the content of the vector table and indicates whether the corresponding exceptions are secure or non-secure. Reset vectors number zero and one explained in the previous slide are not represented. Regarding the security state in which the exception will be handled there are three possibilities. Configurable means that secure software can decide what will be the target security state either non-secure or secure. Banked means that the exception is handled in the current security state. Secure means that the exception is always handled in secure state. For example the non-maskable interrupt or an MI is either handled in secure state or in non-secure state according to a programmable control bit present in a secure only register. A banked exception is taken in the secure state in which it occurs. For example the memory management fault which is taken in case of access permission violation is handled independently in each security domain. A new system exception called secure fault is introduced in the ARM v8m mainline for handling of security violations. It always targets the secure state. When an interrupt is taken while the current security state is non-secure and the interrupt source is non-secure the sequence is the same as the v7m exception mechanism. The caller saved registers are automatically saved when the exception is taken and automatically restored upon execution of the exception return instruction. The interrupt service routine is executed in non-secure state. When an interrupt is taken while the current security state is non-secure and the interrupt source is secure the unique difference is that the interrupt service routine is executed in secure state. Caller saved registers are pushed and popped to and from the non-secure stack. When an interrupt is taken while the current security state is secure and the interrupt source is secure the sequence is the same as v7m exception mechanism. The caller saved registers are automatically saved when the exception is taken and automatically restored upon execution of the exception return instruction. The interrupt service routine or ISR is executed in secure state. When an interrupt is taken while the current security state is secure and the interrupt source is non-secure a risk of register content leakage exists because the general purpose registers contain secure data. Therefore the microcode in charge of register stacking saves all the registers to the secure stack and then writes zero to all of them prior to starting the execution of the non-secure ISR. 21 clock cycles are needed to achieve this register stacking. Unstacking is performed from the secure stack and restores the contents of all the general purpose registers. This sequence details the tail chaining from a secure interrupt service routine to a non-secure interrupt service routine. At the beginning the processor runs in secure state when a secure interrupt is requested. The microcode saves the caller saved registers to the secure stack. Then a non-secure interrupt is requested. When the exception return instruction is executed at the end of the secure ISR the microcode in charge of tail chaining automatically saves all callee saved registers to the secure stack so that all general purpose registers or gpr have been saved. All gprs are automatically cleared to zero prior to starting the execution of the non-secure interrupt service routine. At the end when the exception return instruction is executed the microcode restores all the gprs from the secure stack before resuming the execution of the secure application. Both secure and non-secure software are in charge of assigning a priority to any exception source. The lower the value the higher the priority. A security issue could happen if the non-secure software selects high priority levels close to zero in order to mask the secure interrupts. The v8m features a secure control bit called prys that shifts the non-secure programmed priority level one bit to the right inserting a one to the left. The consequence is that effective non-secure priority levels are in the range of 0x80 to 0xfe. Thus any secure interrupt can be programmed with a higher priority that non-secure wants. The v7m priority boosting registers pry mask, fault mask and base pry used to set the execution priority level are banked in the v8m mainline between secure and non-secure states. When the trust zone security is active a peripheral can be either secureable or trust zone aware as follows. Securable. A peripheral is protected by an AHB APB firewall gate that is controlled by the TZSC controller to define security properties. Trust zone aware. A peripheral is connected directly to the AHB or APB bus and implements a specific trust zone behavior such as a subset of registers being secure. Trust zone aware AHB masters always drive the H non-sec signal according to the security mode as Cortex M33 core and DMA. The trust zone security controller or TZSC which is a part of the module called GTZC defines the secure and privileged state of slave and master peripherals. Therefore the TZSC itself is a secure block. Rights to the under-flight decryption engine or OTF deck are always secure when trust zone is enabled. This table shows an example of eight typical SAE regions mapping on top of IDAU fixed regions. Based on IDAU security attribution the flash system SRAMS and peripheral memory space is aliased twice for secure and non-secure state. However the external memory space is not aliased. The user can split and choose the secure non-secure or NSE regions for external memories as needed. In the STM32L5 the security state of internal memories and internal peripherals is not hard coded. It's programmable in the GTZC module. Consequently the address range containing peripheral registers or portion of internal memories can be programmed as being secure or non-secure. This is achieved in the SAU. However the number of regions supported by the SAU which is only eight doesn't enable the user to select the security attribute for each peripheral and regions of internal memories. Address aliasing is implemented to map the peripheral all memory address ranges at two different addresses one in a secure region the other in a non-secure region. The slide describes how the USART1 address range is aliased. In the physical memory space the USART1 has a unique address range. However it's visible to internal masters at two different addresses. 0x401300 when USART1 is programmed as a non-secure peripheral 0x5013800 when it's programmed as a secure peripheral. Thus the original address in the physical memory is aliased in two different addresses. The AHB5 protocol indicates the security attribute of a transaction request through the H non-sec signal. This table provides the security attribute of the transaction output on AHB5 bus when the processor fetches instructions according to the security attribute of the targeted memory defined by the combination of SAU and IDAU settings. The transaction generated over the AHB5 bus is marked as secure when the processor performs an instruction fetched into a region defined as secure or secure non-securable callable by the combination of SAU and IDAU attributes. Note that the CPU current security state is not taken into account to define the instruction fetch security attribute. This figure summarizes the various protections that check the secure attribute of instruction fetches. Two levels of protection are implemented. One is the SAU IDAU security attribution units. The other one is the definition of secure areas in the flash memory. The following instruction fetches are successful. Running in secure state and fetching from a region marked as secure in both SAU IDAU and flash controller. Running a non-secure state and fetching from a region marked as non-secure in both SAU IDAU and flash controller. All other instruction accesses are blocked either by SAU IDAU or by the flash security protection. In particular, a processor running in secure state is not permitted to fetch instruction from a non-secure area. This figure is slightly different to the previous one in that the SAU IDAU declare the region as secure non-secure callable. In this case, any instruction access initiated in secure non-secure state is accepted by the SAU IDAU protection and the transaction is marked as secure on the AHB5 bus. When the target area is programmed as non-secure in the flash controller, the transaction is blocked and an error is signaled. When the target area is programmed as secure in the flash controller, the transaction is accepted and transition from non-secure to secure is effective only when the instruction called by the non-secure software is a secure gate or SG. If the first instruction accessed in the secure non-secure callable area is not SG, the transition to secure state is not performed. This table summarizes the rules which define the AHB5 transaction type according to the target address space when the processor accesses data. When the processor runs in non-secure state, the data transactions are marked as non-secure. When it runs in secure state, the data transactions are marked as either secure or non-secure depending on the SAU IDAU setting. Note that enabling secure software to access non-secure address spaces is mandatory to share memory. One important use case is encrypting in a secure state a non-ciphered buffer allocated by non-secure software. When the processor runs in secure state an SAU IDAU map the region as non-secure, the data transaction on AHB5 is tagged as non-secure because the data accessed by the secure software is non-trusted and secure firewalls shall not be passed. Non-secure access towards a secure area is automatically blocked at the SAU IDAU level. This slide details the security protection mechanisms implemented when the processor accesses a secureable IP programmed as non-secure in the peripheral protection controller of the GTCC. If non-secure software uses the secure aliased address the SAU IDAU units block the transaction. If non-secure software uses the non-secure aliased address, the transaction is successful. Note that secure software can use two different addresses to access the non-secure peripheral, the one in the secure aliased address range and the one in the non-secure aliased address range. When secure software uses the non-secure areas, the transaction that occurs on AHB5 is tagged as non-secure. This slide details the security protection mechanisms implemented when the processor accesses a secureable IP programmed as secure in the peripheral protection controller of the GTCC. Any attempt to access this peripheral in non-secure state results in a failure. The transaction is successful only when the processor runs in secure state and uses the secure alias region. This slide details the security protection mechanisms implemented when the processor accesses a trust zone aware IP containing both secure and non-secure address ranges. Only secure software is permitted to access the secure parts of the peripheral by using the secure alias. Both secure software and non-secure software are permitted to access the peripheral registers through the non-secure alias. However, the security protection implemented in the trust zone aware peripherals prevents non-secure software from accessing secure address ranges. The trust zone security module has relationships with the following modules global trust zone controller or GTCC, embedded flash memory or flash.