Cortex-M23/33与Cortex-A的TrustZone差异及跨核原型开发可行性咨询

Great question—let’s break this down into two clear parts: the core differences between TrustZone implementations on these Cortex cores, and whether prototyping Cortex-M23 apps on Cortex-A is a viable path.

Key Differences Between Cortex-M23/33 and Cortex-A TrustZone #

TrustZone’s core goal (isolation between secure and non-secure code) is consistent, but the implementations are tailored to their target use cases:

• Target Workloads & Scope
  Cortex-A’s TrustZone is built for full-featured operating systems (Linux, Android) in high-performance systems. It splits the entire system into two "worlds": a rich, non-secure world running the main OS, and a secure world running a dedicated trusted OS (like OP-TEE) that manages multiple complex trusted apps.
  Cortex-M23/33’s TrustZone is optimized for microcontroller use cases—small footprint, real-time constraints, bare-metal or RTOS environments. It uses simpler Secure/Non-Secure states instead of full worlds, focusing on isolating individual peripherals and lightweight trusted routines rather than entire OSes.

• Isolation Mechanisms
  Cortex-A relies on an MMU (Memory Management Unit) to enforce address space isolation between worlds, with virtual memory support. This allows for fine-grained, OS-managed isolation.
  Cortex-M23/33 use an MPU (Memory Protection Unit) paired with a TrustZone Controller (TZPC) to partition physical memory regions and peripherals into Secure/Non-Secure domains. The MPU here is far simpler than an MMU, focused on block-level protection without virtual memory.

• Context Switching & Entry/Exit
  Cortex-A uses SMC (Secure Monitor Call) exceptions to switch between worlds, which involves full context switching between the two OSes—this has higher overhead but enables complex inter-world communication.
  Cortex-M23/33 use lightweight entry points: secure interrupts, BLXNS/BLX instructions for cross-state branches, and SVC for secure function calls. Context switches are minimal since there’s no full OS to switch between, just application-level code.

• Software Stack Requirements
  Cortex-A’s secure world requires a trusted OS to manage resources and trusted apps. The non-secure world runs a standard general-purpose OS.
  Cortex-M23/33 typically run bare-metal code or a small RTOS in both Secure and Non-Secure states—no full trusted OS is needed, keeping the stack lean and low-latency.

Can You Prototype Cortex-M23 Apps on Cortex-A? #

The short answer: You can build a functional prototype for high-level logic, but there are critical gaps that will require rework when migrating to Cortex-M23.

What Works for Prototyping #

• Security Logic Validation: If your app’s core security flow (e.g., secure data handling, cross-state function calls) is hardware-agnostic, you can replicate this using Cortex-A’s TrustZone. For example, using a secure monitor to mimic MPU-style isolation, or separate processes to represent Secure/Non-Secure contexts.
• Application-Level Code: Any code that doesn’t interact with hardware or core Cortex-M-specific features can be tested in both secure and non-secure environments on Cortex-A.

Critical Challenges & Migration Risks #

• Hardware Peripheral Incompatibility: Cortex-M23 is a microcontroller core, so it interfaces with MCU-specific peripherals (GPIO, low-power timers, on-chip sensors) that are vastly different from Cortex-A’s system-level hardware. Any hardware-dependent code will need a full rewrite for your target Cortex-M23 chip.
• Instruction Set & Core Behavior: Cortex-M23 uses ARMv8-M (Thumb-2 only, simplified privileged model), while Cortex-A uses ARMv8-A (supports ARM/Thumb, full MMU-based privilege levels). Privileged instructions, interrupt handling, and memory access models differ significantly—code relying on Cortex-A-specific features won’t translate directly.
• TrustZone Implementation Gaps: The way isolation is enforced (MPU vs MMU, TZPC vs system-level controllers) is fundamentally different. Code built for Cortex-A’s TrustZone APIs or mechanisms will need to be completely reworked to fit Cortex-M23’s streamlined model.
• Real-Time Performance: Cortex-M23 is optimized for low-latency real-time tasks. Cortex-A, even in secure mode, has higher overhead from OS context switches and MMU operations—your prototype’s performance won’t reflect the real-time behavior of the final Cortex-M23 system.

Better Alternatives #

If you need a more accurate prototype before the Cortex-M23 chip is available, consider using ARM’s Virtual Hardware model for Cortex-M23—it emulates the exact core, peripherals, and TrustZone behavior without the gaps of a Cortex-A prototype.

内容的提问来源于stack exchange，提问作者Stefan