Security and Safety by Spatial and Temporal Isolation: Design Pattern Behind TZ, SMMU, MPU and MPAM

MMU, MPU, MPC, PPC, TrustZone SAU, IO-SMMU, TZASC, Qualcomm VMIDMT/XPU, NXP RDC, MPAM — once you see the pattern, they all look identical

I’ve spent the last few weeks working across two very different engineering domains: PSA L2 certification Assessment for an Arm Cortex-M55 SoC, and spatial & Temporal isolation to achieve FFI (Freedom from Interference) for a mixed-criticality platform. Different silicon, different standards, different threat models.

At some point I noticed I was explaining the same concept repeatedly — to different audiences, in different vocabulary — and it was the same concept every time.

Here it is in one line: > Every hardware protection mechanism is an answer to: (initiator identity) × (target resource) → (access policy)

That’s the skeleton underneath all of them — TrustZone, SAU, MMU, MPU, MPC, PPC, IO/SMMU Stage 2, TZASC, Qualcomm VMIDMT and XPU, NXP RDC, Xilinx XMPU, AMD TMR, ARM MPAM. They are all implementations of this three-part formula, differing only in what kind of identity they track, what kind of resource they guard, and where on the bus fabric they sit.

Why this matters in practice

When you understand the pattern, encountering a new SoC’s proprietary protection controller stops being intimidating. You only need to ask three questions:

1. Who does it identify?— a CPU TrustZone security state, a DMA StreamID, a Domain ID, a Partition ID, a Qualcomm VMID?
2. What resource does it guard? — a memory range, a peripheral, a cache partition, DRAM bandwidth? 3. Who programs and locks the policy?— EL3 firmware, a hypervisor, secure boot, a Root of Trust domain?

The answers immediately tell you what the component can and cannot do — before you read a single register description.

The one structural insight most engineers miss

Every mechanism sits on one of two sides of a bus transaction:

1. I*nitiator side (tags the transaction with an identity)
2. Target side (checks the tag and enforces policy).*

This distinction explains the single most common gap in real security architectures: Initiator-side mechanisms only protect against the CPU. The TrustZone SAU, the MMU, the MPU — none of them see DMA transactions. A DMA engine has no TrustZone state machine. It generates bus transactions that bypass everything the CPU’s security infrastructure enforces.

This is why a system with SAU but no MPC or PPC can have a correctly configured TrustZone and still be broken — a misconfigured DMA channel reads straight through it. Target-side mechanisms — MPC, PPC, IO-SMMU Stage 2, TZASC, Qualcomm XPU, NXP RDC — protect against all initiators equally. They are the load-bearing components of any serious security or safety architecture.

How Qualcomm Snapdragon implements the pattern

Qualcomm’s official access control white paper for Snapdragon SoCs is one of the clearest vendor articulations of this framework I’ve encountered — they explicitly use the initiator/target framing themselves.

Snapdragon uses three hardware components:

1. VMIDMT (Virtual Master ID Mapping Table): is the initiator-side identity injector. It takes hardware-fixed initiator identifier signals and maps them to outgoing security attributes — the VMID (Virtual Master ID) and the NS/Secure signal — that travel with every transaction on the bus. This is structurally identical to ARM’s MSW pattern: a component that wraps non-CPU masters and injects a domain identity onto their transactions.

2. XPU (eXternal Protection Unit): is the target-side policy enforcer. It sits in front of memory regions and peripheral register banks and checks incoming security attributes against its policy table. XPU operates in three modes: MPU (programmable memory ranges), RPU (fixed peripheral register ranges), and APU (fragmented address ranges). This covers the full spectrum of what ARM MPC, PPC, and TZASC do — but as a single unified component type instantiated differently per resource.

3. SMMU is used identically to ARM’s SMMU — address translation and access control for non-CPU bus masters, with Stage 1 controlled by the OS and Stage 2 controlled by the Hypervisor or TrustZone.

What makes Qualcomm’s model architecturally distinctive is multiple mutually-distrusting Root of Trust domains. ARM’s model has one trust root (TrustZone at EL3). Qualcomm explicitly supports two independent, mutually-distrusting ROT domains — TrustZone and a separate Qualcomm ROT — each controlling their own VMIDMT outputs and XPU resource groups independently. Neither can modify the other’s security attributes. This is a more expressive trust model than the binary ARM Secure/NonSecure hierarchy.

The firmware authentication use case in Qualcomm’s documentation illustrates the full pattern concretely: CPU OS loads Video firmware into DRAM, calls TrustZone via SMC, TrustZone programs an XPU resource group to restrict that DRAM region to Video CPU access only, authenticates the firmware, then releases the Video CPU from reset. This is the exact same pattern as AMD PSP + TMR, and the same pattern as the qcom_scm_pas_auth_and_reset() call visible in the Linux Adreno GPU driver.

Security and safety are the same problem

The security framing is obvious: prevent unauthorised access. The safety framing — Freedom from Interference (FFI) in IEC 61508 and ISO 26262 — is less obviously the same thing, but it is.

FFI requires that a lower-integrity component (an AI inference engine, a comfort ECU) cannot corrupt the memory or timing of a higher-integrity component (a brake controller, a motor safety function). Spatial isolation — the same MPC, IO-SMMU, TZASC, and XPU enforcement — is the hardware basis for that claim.

The one dimension safety adds that pure security doesn’t is temporal isolation: it’s not enough that the AI engine cannot write to the safety controller’s memory; it also cannot starve the safety controller of cache capacity or DRAM bandwidth and cause a deadline miss. ARM’s MPAM extends the same three-part framework to time-domain resources: PARTID as the identity signal, cache ways and DRAM bandwidth as the resource, allocation limits as the policy.

Spatial and temporal isolation together are the complete FFI argument. Most architectures I see have partial spatial isolation and no temporal isolation — which means the safety argument cannot be closed.

The lock pattern: the step everyone forgets

One more thing the pattern makes visible: every one of these mechanisms needs a configuration lock to be hardware-enforced rather than merely software-configured.

If IO-SMMU Stage 2 tables can be rewritten by Linux at EL1, the isolation is a software convention, not a hardware guarantee. If MPC policy registers can be modified post-boot, any code execution can undo the protection. If Qualcomm XPU resource group ownership is not locked after boot, a compromised kernel could reprogram the policy. The lock registers — HDP on STM32, SMMU_s_CONF on the IO-SMMU, EL3 write-protect on TZASC, Qualcomm ROT domain ownership locks — are what transform “the firmware configured this” into “the hardware is the firewall.”

Security and safety configuration is a boot-time transaction, not a runtime API. This mental model shift is the difference between an architecture an evaluator will accept and one that won’t pass scrutiny.

I’ve written a full technical deep-dive covering all of these mechanisms — TrustZone SAU/IDAU, MMU exception levels, MPU, MPC/PPC/TGU, IO-SMMU 2-stage translation (hypervisor and hypervisorless AMP), TZASC, Qualcomm VMIDMT/XPU/SMMU and the Snapdragon trust hierarchy, NXP RDC/CSU, Xilinx XMPU/XPPU, AMD TMR/TMZ, and ARM MPAM — with a unified lookup table that places every mechanism in the framework. It includes interactive diagrams of the SMMU nested translation walk and the full taxonomy across security and safety dimensions.

[Read the full technical article here → Security and Safety by Isolation]

This analysis draws on work across PSA Certified Level 2 certification for Cortex-M55, SMMU-based mixed-criticality platforms, and comparative architecture review of STM32U585, NXP i.MX8x, Xilinx UltraScale+ MPSOC, and Qualcomm Snapdragon.