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
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?