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
Hi,
XOM is not exactly an architecture feature. But in ARMv8-M we made it easier to handler XOM in software.
Previously in ARMv6-M, using XOM technique is inefficient for software because MOVW and MOVT are not available. In ARMv8-M these two instructions are available for both Mainline and Baseline, so the same firmware protection techniques can be used.
The address range for XOM is defined by chip designers.
regards,
Joseph
Hello Joseph Yiu,
thank you for the explanation.
But It sounds that XOM will be an implementation matter.
I would like to know the relationship Between XOM and ARMv8-M.
I think that XOM is one of ARMv8-M features.
Are there some registers which specify the XOM address range?
Best regards,
Yasuhiko Koumoto.
For ARMv8-M mainline stack limit feature is available to both Secure and Non-Secure sides.
Great!
The XOM technique does not require MPU feature. (Do not confuse it with exeucte never "XN" memory attribute which is configurable by MPU).
XOM requires the memory interface hardware to ignore data accesses (including debug access). This can be done by filtering out data transfers by checking a bus sideband signal (e.g. HPROT[0] in AHB/AHB5), or in the case for Cortex-M3/M4, connecting XOM only to I-CODE bus.
The ARMv8-M baseline architecture is designed for ultra low power and area constrainted designs, with a certain low power target. As a result the designer has to make some tradeoff between functionalities and the power/area, and therefore the stack limit is omitted from current architecture definition. You are correct that this function is useful for Non-Secure RTOS as well, so we will revisit this in the future.
On the Secure side stack limit check is essential to prevent stack overflow which could end up leaking Secure information into Non-Secure world (depending on layout of memory contents).