The next generation of ARM Cortex-M processors will be powered by a new architecture version called ARMv8-M architecture. This document provides a technical overview of various enhancements in the new architecture, as well as an introduction to the security technology, called TrustZone for ARMv8-M. This document also introduces AMBA 5 AHB5 which enables security management at a system level, and covers various use cases of the new technology.
https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/cortex-m-resources
Topics
Document
Introduction
Introduction to the ARMv8‑M Architecture
TrustZone
TrustZone technology for ARMv8‑M Architecture
ARM C Language Extension (ACLE)
ACLE Extensions for ARMv8‑M
Secure software
Secure software guidelines for ARMv8‑M based platforms
System Design
System Design for ARMv8-M
Exceptions and Interrupts
ARMv8‑M Exception Handling
Fault exception
Fault Handling and Detection
Power management and sleep modes
ARMv8-M processor power management secure state protection
Debug
ARMv8‑M Processor Debug
Memory model, MPU
Armv8-M Memory Model and MPU User Guide (doc, example codes)
MPU
Memory Protection Unit for ARMv8‑M based platforms
OS
RTOS design considerations for ARMv8‑M based platforms
ARMv8-M software development with ARM Compiler 6
Chapter 9 : Building Secure and Non-secure Images Using ARMv8-M Security Extensions
TrustZone software development in Keil MDK
Keil Application Note 291: Using TrustZone on ARMv8-M
Security extension details for compiler vendors
ARMv8-M Security Extension: Requirements on Development Tools (latest)
(v1.1)
ARMv8-M software development
EW2017 - Software Development on ARMv8-M Architecture
mbed(TM)OS deployment on Armv8-M
EW2017 - High-End Security Features for Low-End Microcontrollers
RTOS design
EW2019 - How RTOS should work in a TrustZone for Armv8-M environment
TrustZone Secure software
Stack sealing and why it is needed in TrustZone for Armv8-M
Hello Joseph Yiu,
I am re-reading the ARMv8-M Architecture Technical Overview and became to have question. Can you help me?In the document, the context stacking of FPU is described only one case.That is,
In the case that Secure software does use the FPU and Non-Secure interrupt handler does not use FPU, the stacking and unstacking of FPU registers are skipped to provide a faster interrupt handling sequence.
How about the following cases.1) Secure software & Non-Secure interrupt DOES use FPU.2) Non-ecure software & Non-Secure interrupt DOES use FPU.3) Secure software & Secure interrupt DOES use FPU.4) Non-ecure software & Secure interrupt DOES use FPU.
Regarding 1), does the lazy stacking occur?If it does, how are the Secure contexts protected?Regarding 2), 3) and 4), I think there would be no problems if the lazy stacking will occur.
Thank you and best regards,Yasuhiko Koumoto.
That's a Really good whitepaper ! Good Job
Hi,
Yes, you are right that Secure code can be interrupted by a Non-Secure interrupt. That is a key unique feature of ARMv8-M as it enables very low interrupt latency for peripherals, even when the processor is executing Secure code.
And yes, it is possible that Non-Secure ISR then call Secure code again, or a Secure interrupt can also trigger during Non-Secure code. Potentially multiple levels of interrupt ISR from Secure and Non-Secure state can nested together and this is perfectly fine for ARMv8-M operations. Normally we assume that Secure software should allocated enough memory space in the Secure main stack so that it can cope with such interrupt nesting and function calls. However, there are cases that Secure software developers cannot foreseen and therefore both ARMv8-M baseline and mainline provide stack limit checking on Secure side. If the stack point go over a certain limit (specified by a programmable register), a Secure Usage Fault/HardFault will trigger and Secure software can then handle it properly. Therefore the peripheral ISRs do not require special modifications to include this checking.
Regards,
Joseph
If I understand this right then it is possible for a non-secure side interrupt to interrupt the secure side and then call back to the secure side again. So it is fairly essential that there be a stack limit on the secure side as that could happen multiple times. I can see that happening okay by mistake or if the non-secure side is compromised. Is it envisaged that there will sometimes actually be more than one call from the non-secure side to the secure side outstanding in some circumstances, e.g. if an interrupt needs to check something?
Hello Joeph Yiu,
thank you very much for the detailed explanation.
I understood well.
Best regards,
Yasuhiko Koumoto.