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
Sorry for the delay of my reply, I am travelling in Asia (holiday) at the moment.
Lazy stacking feature is enabled by default, and is controlled by FPCCR.LSPEN (no change from Cortex-M4).
Software can switch it off if it need to.
The challenging part would be what is being pushed to the stack:
- R0-R3, R12, LR, PC, xPSR : always push to the stack in exception entry
- S0-S15, FPSCR : stack frame always allocate the space for them if FPU is enabled and floating point context is active (CONTROL.FPCA==1), but the push might be deferred by lazy stacking.
- R4-R11 : push to Secure stack if Non-secure exception occurred running Secure code execution.
- S16-S31: stack frame allocate space for them if Non-secure exception occurred running Secure code execution, and FPCCR_S.TS is 1, and FPU enabled and is active (CONTROL.FPCA=1), but the push might be deferred by lazy stacking.
Hope this helps.
regards,
Joseph