Security and Safety by Isolation

The Universal Problem

A modern SoC is a shared interconnect fabric. Every component — Cortex-A application cores, Cortex-M safety cores, GPU, NPU, ISP, DMA engines, USB controllers, network interfaces — generates transactions on the same bus to reach the same pool of memory and peripherals.

There are no physical walls. A DMA engine can in principle read any byte of DRAM. A compromised GPU driver can issue transfers to addresses it has no business touching. A real-time safety controller sharing a cache with a machine-learning inference engine may find its execution time perturbed by cache pressure it cannot predict or bound.

Both the security problem and the safety problem reduce to the same fundamental question:

Every hardware protection mechanism in this article is a specialisation of one three-part formula:

The dimensions vary — identity may be a CPU security state, a StreamID, a Domain ID, a Partition ID; the resource may be a memory range, a peripheral, a cache partition, or DRAM bandwidth; the policy may be allow/deny, R/W permissions, or a bandwidth cap. But the structure is always the same.

The Master Design Pattern: Two Sides of Every Transaction

Every hardware protection mechanism sits on one of two sides of a bus transaction. This is the most important structural insight in the framework.

The Identity Signal: How Transactions Get Tagged

On ARM-based SoCs, the AMBA AHB5/AXI bus fabric carries security and privilege metadata as sideband signals alongside every transaction:

Signal          Values              Meaning
──────────────────────────────────────────────────────────
HNONSEC         0=Secure, 1=NS      TrustZone security world
AxPROT[1]       0=Priv,  1=Unpriv   Software privilege level
AxUSER[...]     vendor-defined       StreamID, domain tag, etc.

These are hardware wires, not software registers. Every target on the fabric sees them on every transaction. What the target does with them depends on whether it has a policy enforcer in front of it.

StreamID: Identity for Non-CPU Masters

For non-CPU masters (DMA, GPU, NPU), the AxUSER sideband carries a StreamID — a hardware-assigned identifier unique to each master or DMA channel. The StreamID is the "who are you" for non-CPU initiators.

This is the concept that unifies SAU-based TrustZone enforcement (CPU identity) and SMMU-based enforcement (DMA/GPU/NPU identity): both answer the same question — "which domain does this initiator belong to?" — for different classes of master.

Cortex-M: SAU, IDAU, and the NSC Bridge

SAU — The CPU's Own Identity Resolver

The SAU (Secure Attribution Unit) is inside every ARMv8-M core. It maintains up to 8 configurable address regions, each classified as Secure, NonSecure Callable (NSC), or NonSecure. When the CPU generates an access to address X, the SAU resolves X's security classification and tags the outgoing transaction with HNONSEC accordingly. If NonSecure code accesses a Secure address, the CPU faults before issuing any bus transaction.

IDAU — The Immutable Baseline

The IDAU (Implementation Defined Attribution Unit) is vendor-fixed hardware attribution that software cannot modify — ever. The SAU can only raise security above the IDAU floor, never lower it. This prevents an attacker with Secure code execution from reconfiguring SAU to expose previously-secure regions that the IDAU has hardwired.

The NSC Region — Hardware-Enforced API Boundary

The NonSecure Callable region solves the bridge problem: how does NonSecure code call a Secure service without opening an arbitrary hole? Every NSC entry point must begin with the SG (Secure Gateway) instruction. The CPU hardware verifies that cross-domain branches land on SG — not an arbitrary Secure address. Any other pattern causes a fault. This is hardware-enforced API binding at the isolation boundary.

MPC, PPC and TGU: Target-Side Guards

MPC — Memory Protection Controller

The MPC sits on the AHB bus path between the bus matrix and a SRAM or NVM region. It maintains a policy table — one security bit per memory block — and checks every incoming transaction's HNONSEC against that table, regardless of which master sent it.

Granularity varies by implementation: 256 B (STM32L5), 512 B (STM32U5 MPCBB), 16 KB (some Cortex-M55 SoC SSRAMPROT). Layout must respect MPC granularity — you cannot independently secure a structure smaller than one block.

Two violation response modes: Bus error (auditable — CPU gets an exception) or RAZ/WI (silent — read-as-zero, write-ignored; prevents information leakage about whether the resource exists).

PPC — Peripheral Protection Controller

The PPC is the MPC equivalent for peripheral register banks. It sits at the AHB-to-APB bridge. Two ways to secure a peripheral exist — SAU-based (stops CPU only) or PPC-based (stops all initiators). For any PSA or safety certification claim, PPC is required because SAU alone leaves the DMA attack surface open.

TGU — The TCM Special Case

TCM (Tightly Coupled Memory) bypasses the AHB bus matrix entirely. Standard MPC components cannot guard it. The TGU (TrustZone Guard Unit — ITGU for ITCM, DTGU for DTCM) is the dedicated mechanism, maintaining a bitmap of TCM pages at the direct CPU-to-memory interface. Hardware default: all TCM Secure at reset.

STM32 GTZC — Integrated Security Fabric

STM32U5's GTZC integrates MPC + PPC + MSW + violation monitoring into a single peripheral. Its TZIC generates secure interrupts on any policy violation — satisfying the audit requirement that certified firmware can receive, log, and respond to every illegal access attempt.

MSW: Giving Non-CPU Masters a Security Identity

DMA engines and other bus masters have no TrustZone state machine. A Master Security Wrapper (MSW) wraps each non-CPU master and injects HNONSEC and HPROT sideband signals onto its outgoing transactions, based on policy programmed by secure firmware at boot time.

From this point, MPC and PPC cannot tell whether a transaction came from the CPU or a DMA engine — they only see sideband signals. This is by design: the policy should be enforced identically regardless of initiator.

Cortex-A: MMU, Exception Levels, and DACR

Cortex-A introduces Exception Levels (EL0–EL3) — a second isolation dimension orthogonal to TrustZone's Secure/NonSecure split:

EL3  Secure        Secure Monitor (TF-A, EL3 firmware)
EL2  Secure/NS     Hypervisor (KVM, Xen, QHEE, or absent)
EL1  Secure/NS     OS kernel (Linux, RTOS, TF-M S-kernel)
EL0  Secure/NS     Applications, Trusted Apps

Lower ELs cannot access higher ELs' resources — all cross-level access goes through exception trapping (syscalls, HVC, SMC). The CPU's own translation machinery (MMU + page table permission bits) enforces this before any bus transaction reaches the fabric.

DACR — Trust Domains Within the Secure World (AArch32)

AArch32 systems include the DACR (Domain Access Control Register), providing up to 16 trust domains as an additional access control dimension. Each memory page is assigned to a domain number via page table descriptors, and the DACR specifies the access level per domain: No Access, Client (enforced), or Manager (bypassed). This provides intra-world privilege hierarchy — finer-grained isolation of Trusted Applications from each other within the Secure world.

TZASC / TZPC: Target-Side Guards for DRAM and Peripherals

TZASC — TrustZone Address Space Controller

The TZASC (ARM TZC-400 being the most common implementation) sits between the system interconnect and the DRAM controller. It maintains address regions with security attributes and blocks NonSecure transactions to Secure-attributed regions.

Key distinction: TZASC is not a translation mechanism. It does not remap addresses. It is purely a range-permission checker — it looks at the physical address on the bus, checks it against its policy table, and passes or blocks. This makes it structurally identical to MPC at a different point in the fabric (DRAM controller rather than SRAM controller).

TZPC — Peripheral Security Assignment

TZPC is the Cortex-A equivalent of PPC: assigns each peripheral as Secure or NonSecure. NonSecure masters cannot access Secure peripherals. Xilinx XPPU and NXP CSU serve similar roles — vendor implementations of the same target-side peripheral access control pattern.

IO-SMMU: Extending Isolation to All System Masters

The SMMU intercepts transactions from all non-CPU masters before they reach DRAM or peripherals. Every transaction carries a StreamID — the SMMU maps this to a translation context and permission policy via its Stream Table (SMMUv3) or Context Bank table (SMMUv2).

Why Two Stages?

One-stage: OS programs page tables → SMMU enforces. Problem: the OS is the entity you don't fully trust. Giving the OS control of SMMU page tables is giving the fox the key to the henhouse.

Two-stage: Stage 1 is controlled by the untrusted entity (Guest OS). Stage 2 is controlled by the trusted entity (Hypervisor at EL2, or EL3 firmware). Stage 1 expresses intent; Stage 2 independently grants or denies permission at the hardware level.

Qualcomm Snapdragon: VMIDMT, XPU, and Multi-ROT Trust

Qualcomm's official access control white paper for Snapdragon SoCs explicitly uses the initiator/target framing — one of the clearest vendor articulations of the unified framework. Three hardware components provide all access control on Snapdragon:

VMIDMT — Virtual Master ID Mapping Table

VMIDMT 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 bus transaction. Multiple initiators can share one VMIDMT.

Structurally identical to ARM's MSW pattern: a component that wraps non-CPU masters and injects a domain identity onto their transactions. Each ROT domain controls VMID generation for its own domain exclusively — no ROT domain can influence another's security attributes.

XPU — eXternal Protection Unit

XPU is the target-side policy enforcer. It sits in front of memory and peripheral resources and checks incoming security attributes against its policy table. XPU operates in three modes determined at hardware design time:

• MPU mode: Software-programmable contiguous memory ranges (4 KB boundary aligned). Equivalent to ARM MPC/TZASC.
• RPU mode: Fixed-size contiguous ranges, typically peripheral register banks. Equivalent to ARM PPC/TZPC.
• APU mode: Fixed fragmented or contiguous ranges of varying sizes. More expressive than ARM's binary S/NS model — no direct ARM equivalent.

Each resource group in an XPU has a single owning ROT domain. Only the owner can modify that group's access policy. The owner can share the resource with other domains by granting explicit R/W permissions — a capability-based model on top of the identity-based model.

Multiple Mutually-Distrusting ROT Domains

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

The Firmware Authentication Use Case — The Pattern in Action

Qualcomm's firmware authentication flow (visible in the Linux kernel as qcom_scm_pas_auth_and_reset()) illustrates the full three-part framework in concrete operation:

1. CPU OS loads Video firmware from storage → DRAM
   (CPU OS has full access at this point)

2. CPU OS calls TrustZone via SMC, passes firmware address

3. TrustZone validates the address range (no overlap)

4. TrustZone programs XPU resource group:
   → firmware DRAM region = Video CPU only (R/W)
   → CPU OS access: revoked
   (This is the target-side lock — identity × resource → policy)

5. TrustZone authenticates the firmware signature

6. If auth passes → releases Video CPU from reset

7. Video CPU executes authenticated firmware

This is structurally identical to AMD PSP + TMR and to any TEE-based multimedia firmware loading pattern. The pattern is universal across vendors.

NXP i.MX8x: RDC and CSU

RDC — Resource Domain Controller

The RDC introduces Domain IDs (DIDs) — typically 4 domains (0–3) on i.MX8x. Every bus master is assigned a DID. The RDC controls access to memory regions and peripherals per-DID with independent R/W permissions per domain — a superset of TrustZone's binary S/NS model.

DID is the identity signal. RDC memory region registers are the target-side policy table. Domain 0 (safety RTOS) may have RW; Domain 1 (Linux) RO; Domain 2 (multimedia) none — independent per-domain permissions on the same resource.

CSU — Central Security Unit

The CSU provides per-peripheral security policy: SuperUser (privileged Secure access only), User (any access), or Off. Structurally equivalent to TZPC — a target-side peripheral gatekeeper. CSU operates at the peripheral-slot level while RDC operates at memory region and register level.

Xilinx/AMD UltraScale+ MPSOC: XMPU and XPPU

XMPU (Xilinx Memory Protection Unit) sits in front of memory controllers (DDR, OCM) and enforces per-region access control with a master whitelist per region. Each region specifies which AXI Master IDs are allowed access — a superset of the binary S/NS model, closer to Qualcomm's XPU resource group model.

XPPU (Xilinx Peripheral Protection Unit) does the same for peripherals. Each peripheral specifies an allowed set of Master IDs. The AXI Master ID is the identity signal — equivalent to HNONSEC on ARM, DID on NXP, VMID on Qualcomm, StreamID in SMMU.

Xilinx's CSU (Configuration Security Unit) on UltraScale+ is the root-of-trust service hub — managing boot security, key provisioning, and hardware crypto acceleration. Not primarily an access controller; equivalent in role to ARM TF-A EL3 services.

AMD GPU: TMR and TMZ

TMR — Trusted Memory Region (Access Control)

TMR is a defined DRAM region that the GPU's PSP (Platform Security Processor — AMD's secure enclave equivalent) restricts to its own access. Other GPU engines and the host CPU cannot access it. Structurally equivalent to TZASC: a target-side range checker at the GPU memory controller.

TMZ — Trusted Memory Zone (Confidentiality)

TMZ is a confidentiality mechanism, not an access controller. Memory pages marked as TMZ are encrypted/decrypted transparently by the GPU memory controller using a per-context key. Even if another master DMA-reads the physical RAM, it gets ciphertext. This sits at Layer 7 in the defence-in-depth stack — rendering data useless even when access control is bypassed by a physical attacker.

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, ISO 26262, and ISO 13849 — is less obviously the same thing, but it is.

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

MPAM: Temporal Isolation — The Missing Half of FFI

Spatial isolation prevents a non-safety component from writing to safety memory. But it cannot prevent it from starving the safety controller of cache capacity or DRAM bandwidth, causing deadline misses. This is temporal interference — and it breaks FFI just as surely as a memory write would.

ARM's MPAM (Memory System Resource Partitioning and Monitoring, ARMv8.4-A) extends the three-part framework to time-domain resources:

Cache Partitioning

MPAM-aware caches assign each PARTID a subset of cache ways. A process with PARTID 2 can only occupy the cache ways assigned to partition 2 — it cannot evict cache lines belonging to PARTID 1 (the safety partition). Cache behaviour becomes deterministic per-partition, enabling WCET analysis closure.

DRAM Bandwidth Control

Each PARTID can be assigned a maximum DRAM bandwidth share. An NPU running matrix multiply at full bandwidth cannot starve the safety controller's memory accesses. The "noisy neighbour" problem is replaced by bounded, deterministic resource allocation.

The Lock Pattern: The Step Everyone Forgets

Every mechanism discussed needs a configuration lock to be hardware-enforced rather than merely software-configured. Without it, the isolation is a software convention — not a hardware guarantee.

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.

Unified Lookup Table

Every mechanism mapped to the four-part template: identity signal, resource type, enforcement side, policy authority.

Engineer Checklist

Interactive checklist for architecture review. Click to mark items complete.