EN 
DE 
The Armv8-M architecture brings fundamental security to Cortex-M devices, thus enabling greater protection for IoT systems. But how does the “Secure Exception Priority Boosting” feature perform in practice? Security problems in the Internet of Things (IoT) often stem from inadequate protection for devices at the edge of a connected system. A lack of computing power and storage, and of course cost pressures, are frequently cited as reasons why these devices cannot be adequately protected. Hackers are therefore increasingly targeting smart sensors as attack vectors across the entire network. To better protect vulnerable endpoints, the use of multiple MCUs was also investigated, with one or more dedicated exclusively to security functions such as encryption and authentication. Unfortunately, this quickly leads to increased complexity and costs. Introduced in 2015, Arm added TrustZone security extensions for Cortex-M microcontrollers (MCUs) to its 32-bit Armv8-M architecture. With security features comparable to those found in many Cortex-A application processors, Armv8-M brings fundamental security to Cortex-M devices and ensures greater end-to-end security in IoT systems. Even in the extensive Arm Technical Reference Manuals, the topic of "Secure Exception Priority Boosting" in the new v8-M architecture leaves much room for interpretation. The question of how this feature actually behaves in practice remains unanswered. This is reason enough to take a closer look and empirically determine its behavior through experiments with various controllers.
Developing in the secure and non-secure worlds
The TrustZone now provides a secure and a non-secure area within a single microcontroller. The microcontroller always executes a program in one of these two areas and can switch back and forth between them. Security features ensure that a program running in the non-secure area cannot easily access the secure area, where passwords and encryption programs, for example, are protected. Interrupts and exceptions are also handled in their respective areas, or rather, their handlers are executed. The software is developed independently for each area. Therefore, as a software developer, you either develop in both areas or only in one. Note: In Arm architectures, a distinction is made between... Exceptions and Interrupts as a term for interruptions. In the Cortex-M architecture, the difference between the two terms is very small. For better readability, I will only use the term interrupts from now on, even though both terms would usually make sense and be correct for the sake of completeness.
„The "PRIS" bit compresses the priorities of interrupts in the non-secure area.
In v8-M controllers with TrustZone as a security extension, interrupts are handled by handlers in either the secure or non-secure domain. Each of these two domains has access to the complete priority logic for handling interrupts. This means that high-priority and low-priority interrupts are possible in both the secure and non-secure domains. While this sounds appealing, it raises the question of how a software architect can design the system so that the handling of low-priority interrupts in the secure domain is not interrupted by a high-priority interrupt from the non-secure domain. Since the M23 only has two priority bits for just four possible priorities, programmers have limited design flexibility. 
When customer projects run in the non-secure environment, while security programs are supposed to run independently and inaccessibly in the background, who ensures that interrupts in the non-secure environment aren't also assigned high priorities? That's precisely what the "Secure Exception Priority Boosting" feature is for. It's activated by setting the "PRIS" bit in the secure environment. Activating it simply compresses all interrupt priorities in the non-secure environment into the lower half of the priority scale. The non-secure environment doesn't even notice this. While the priority appears high when read, in reality, it's only in the middle range during evaluation. However, the calculation isn't quite perfect yet.
Reassessment of priorities behind the scenes
Upon examining the implementation details, it became apparent that the core design was implemented in two different ways, depending on whether it was the Basic or Main architecture. And the winner is: the M23's Baseline architecture. This is because the limitation of priority interrupts to two bits, inherited from the v6-M architecture (Cortex-M0, M0+), makes compressing the interrupts to the lower half practically impossible. Therefore, priority boosting virtually adds a third bit. Each of the two domains retains its two bits. While the Secure domain continues to use bits 7 and 6, the two Non-Secure bits are shifted down one bit position, to bits 6 and 5, when the "PRIS" bit is set, during priority evaluation. As mentioned, this happens behind the scenes. 
The effective priorities are thus allocated in such a way that the two highest priorities are reserved exclusively for the secure area. Since interrupt handling is not interrupted when priorities are equal, the following scenarios result:
- An interrupt in the Secure World can have priorities of 0, 64, 128, or 192.
- If the PRIS bit is not set and therefore priority boosting is disabled, the same priorities apply to interrupts in the non-secure world.
In the further case, if the PRIS bit is set and thus priority boosting is enabled:
- An interrupt in the non-secure world can have priorities of 128, 160, 192, or 224.
- An interrupt in the secure environment with one of the two highest priorities is always executed independently of the non-secure environment. This may interrupt any ongoing non-secure processing.
- An interrupt in the secure domain can only be interrupted by an interrupt in the non-secure domain if the latter has the lowest of the four priorities (192) and the "interrupter" from the non-secure domain has the highest or second-highest priority (128 or 160).
- An interrupt in the secure area can be delayed by a currently running non-secure interrupt handler if both have the same priority. This can occur with priorities 128 and 192. The later interrupt appends itself to the handling of the current interrupt using the tail-chaining feature.
In the Main Architecture The M33, M35, and M55 chips offer more priority bits. Similar to the v7-M architecture, the chip designer can choose between a minimum of three and a maximum of eight bits. 
Here is an example with five implemented bits and the resulting 32 possible priorities: 
Here too, the PRIS bit shifts the priorities in the non-secure world one bit position to the right; the least significant implemented bit is lost and is evaluated as 0 regardless of the set bit value. 
Undesired system behavior costs one priority bit.
However, this method presents a problem: Setting or clearing the PRIS bit in the secure side alters the preemption behavior in the non-secure side. In unfavorable circumstances, this can lead to a non-secure interrupt sometimes interrupting another and other times having to wait its turn. From the non-secure perspective, this is non-deterministic behavior, as it's impossible to even check whether the PRIS bit is set on the secure side or not. How does this undesirable system behavior arise, and how can it be prevented? The good news is: It can be prevented – but at the cost of a priority bit that cannot be used on the non-secure side. An example to better understand this:
- Our example chip implements five bits.
- On the non-secure side, all five bits should be used as group bits; that is, none of the five bits should be configured as a subpriority bit. This is already a v7-M architecture feature and is therefore assumed to be known here (the group priority must be set to one of the values 5:3, 6:2, or 7:1).
- An interrupt A should be handled on the non-secure side with the second lowest priority, i.e., with priority 240.
- An interrupt B should be handled with the lowest priority on the non-secure side, i.e., with priority 248.
- Interrupt B is currently being executed by its interrupt routine.
- Now, interrupt A, the one with the higher priority, is up for processing:
- Scenario 1 – The PRIS bit on the secure side is not set: The interrupt handling of interrupt B is interrupted as expected and continues after interrupt handling A has finished.
- Scenario 2 – The PRIS bit on the secure side is set: Interrupt handling for interrupt B is NOT interrupted. The handling of the supposedly higher-priority interrupt A is appended to the handling of interrupt B via tail chaining.
- The cause of this unexpected behavior lies in the bit shift during priority handling. The higher priority 240 (0b11110000) is achieved by shifting and inserting a leading 1 to 248 (0b11111000), and is therefore the same as interrupt B.
One avoidance strategy could be to simply not use the last implemented priority bit and live with half of the implemented priorities. This avoids the undesirable behavior. For example, if the last implemented bit is always set to 0, then it doesn't matter whether it is truncated during priority evaluation or not, depending on whether the PRIS bit is currently set on the secure side.
Conclusion
In the v8-M baseline architecture of the M23, priority boosting is a good option, as it effectively creates a virtual third bit. For the M33, M35, and M55, it's crucial to ensure that priority boosting is not used on the secure side. This cannot be prevented or verified from the non-secure side. Therefore, it's best to use only every other priority on the non-secure side to avoid any unwanted side effects from priority boosting.
Further information
MicroConsult expertise on the topic of microcontrollers
MicroConsult Training & Coaching on the topic of Arm/Cortex microcontrollers
