TrustZone for Armv8-M

• By 2015 the IoT market needed per-device cryptographic identity: secure boot, firmware update signatures, attested telemetry.
• Adding a second secure-element chip (SE050 etc.) doubled BoM cost and board area.
• On A-profile, TrustZone had been doing the same job since 2004 (phones). Arm re-architected the concept for MCUs with Armv8-M (2016).
• v8-M TrustZone is now the backbone of PSA Certified, Trusted Firmware-M, and most IoT security standards.

Every address has a security attribute determined on every bus access by:

1. IDAU — Implementation-Defined Attribution Unit. Hard-wired by the SoC vendor; typically partitions the 4 GiB at power-of-two boundaries.
2. SAU — Security Attribution Unit. Programmable by the Secure kernel at runtime; up to 8 regions.

Result: attribute ∈ { Secure, Non-Secure, Non-Secure Callable (NSC) }.

Example attribution of the flash region: mostly Secure, with a small NSC "door" holding gateway veneers, then a Non-Secure chunk for application firmware.

• Up to 8 programmable regions (or 0/4/8 by impl option).
• Each region: base + limit (32-byte-aligned), plus attribute bits:
  • ENABLE
  • NSC (non-secure-callable)
• Attribute encoding:
  • region match, NSC=0 → Non-Secure
  • region match, NSC=1 → NSC
  • no region match → Secure (default)
• Configured only from Privileged Secure. NS code cannot read or write the SAU.

/* Mark 0x0807_F800..0x0808_0000 as NSC (veneers) */
SAU->RNR  = 0;
SAU->RBAR = 0x0807F800UL;
SAU->RLAR = 0x0807FFE0UL | (1u << 1) | 1;  /* NSC + ENABLE */

/* Mark 0x0808_0000..0x080F_FFFF as NS (app flash) */
SAU->RNR  = 1;
SAU->RBAR = 0x08080000UL;
SAU->RLAR = 0x080FFFE0UL | 1;              /* ENABLE */

/* Everything else stays Secure by default */
SAU->CTRL = 1;                              /* ENABLE SAU */
__DSB(); __ISB();

• Implemented entirely by the SoC vendor; not configurable at runtime.
• Typical scheme splits a region in half:
  • lower half → Non-Secure alias
  • upper half → Secure alias
  Same underlying memory, two views. Accessing the "wrong" alias from the wrong state → SecureFault.
• This trick means NS and S code can share an address space and a memory chip, with hardware-enforced mirroring.

• A sub-class of Secure memory — marked NSC by SAU.
• Only memory with the NSC attribute may hold entry points that NS code is allowed to call.
• The very first instruction in an NSC-marked 32-bit slot must be SG — Secure Gateway. Anything else → SecureFault on NS call.
• Rationale: prevents an attacker from jumping into the middle of a Secure function via a crafted pointer. The only door is an SG.

/* Veneer (NSC) section in Secure image */

  .section ".gnu.sgstubs"        /* linker places in NSC */

  .global __acle_se_crypto_decrypt
__acle_se_crypto_decrypt:
    SG                              ; secure gateway entry
    B    crypto_decrypt_impl        ; tail-call to real impl

The compiler emits these veneers automatically when a function is attributed cmse_nonsecure_entry.

SG   ; Secure Gateway

; Preconditions:
;   current state = Non-Secure
;   PC  is in an NSC region
;   SG is the first halfword at this address

; Effects (atomically):
;   switch to Secure state
;   clear FAULTMASK_NS to avoid FAULTMASK escape
;   return-address LR bit[0] = 0 (FNC_RETURN tag)
;   pipeline refetches in new state

• One instruction does what took many on A-profile.
• Inside Secure, the function executes normally.
• Returning is just BXNS LR (see next slide).
• If SG is executed in any other context (already Secure, or PC not in NSC) → NOP on Secure side, or SecureFault.

• BXNS clears LR bit 0 and tags it so the return address is marked non-secure.
• The CPU pushes an integrity signature when the call crosses domains, so attempts to forge the return path fail.
• BXNS is the only legitimate way to leave Secure. An ordinary BX lr with an LR pointing into NS memory → SecureFault.

/* Secure library header, shared with NS */

#include <arm_cmse.h>

/* Exported to NS */
__attribute__((cmse_nonsecure_entry))
int psa_mac_sign(const uint8_t *buf,
                 size_t         n,
                 uint8_t       *out);

/* Callback called from S back into NS */
typedef void (*ns_log_t)(const char *)
    __attribute__((cmse_nonsecure_call));

• cmse_nonsecure_entry — marks an exported function; compiler emits an SG-gated veneer, clears caller-saved regs that might leak S state before BXNS.
• cmse_nonsecure_call — marks a pointer to NS code; compiler emits BLXNS with the right safety scrubbing.
• CMSE helper intrinsics like cmse_check_address_range() let the Secure handler verify that an NS pointer really points into NS memory — essential defence against the "Bubble" attack.

• Each external IRQ has an ITNS bit in NVIC_ITNS[n]: 0 = IRQ targets Secure, 1 = NS.
• ITNS is writable only from Privileged Secure. NS cannot re-target an IRQ.
• IRQ of priority higher than current state may preempt, even across domains — that is when the integrity signature is stacked.
• System exceptions (HardFault, NMI, SecureFault, BusFault) may be configured S-target or NS-target via AIRCR.BFHFNMINS.

S preempts NS

1. NS code running; S-targeted IRQ arrives at higher priority.
2. CPU stacks 8 "basic" words on NS stack.
3. CPU then stacks an additional context (R4-R11, "state context") plus a 4-word integrity signature, again on the NS stack.
4. Switches to Secure handler; all caller-saved NS regs are cleared.
5. On return, the signature is verified. Mismatch → Secure fault.

NS preempts S (rare)

• Only possible if an NS IRQ has priority higher than the executing S handler.
• By default, NS is not allowed to preempt S — the AIRCR.PRIS bit forces NS priorities to the low half.
• When it does happen, additional S-context is stacked on the S stack (protected from NS read).

• On any exception that crosses state, CPU pushes a 4-word "signature frame" to the incoming side's stack.
• Contains 0xFEF5EDA5 as a magic tag, plus state information.
• On exception return, CPU checks the signature. If it has been altered → the CPU does not restore the stacked context and raises a Secure fault.
• Defends against:
  • NS code corrupting the S-return path,
  • NS code forging an EXC_RETURN into S,
  • Race conditions where NS sees a partial S frame.

Platform Security Architecture (PSA)

• Arm-led specification defining a set of MCU security properties:
  • Attestation (prove identity & firmware version)
  • Cryptography (symmetric, asymmetric, hash)
  • Secure storage
  • Secure firmware update
  • Boot ROM & chain-of-trust
• PSA Certified levels 1/2/3: increasingly stringent evaluation.

Trusted Firmware-M (TF-M)

• Open-source reference implementation of the PSA Secure-side runtime.
• Runs entirely in Secure state; exposes PSA APIs to NS via NSC veneers.
• Includes crypto (via Mbed TLS), secure storage, attestation, firmware update (MCUboot).
• Ships as the default secure firmware for STM32U5/L5, Nordic nRF54, NXP LPC55, Renesas RA.
• github.com/trustedfirmware/trusted-firmware-m

• DAUTHCTRL register in SCB has four enable bits — one per {S, NS} × {halting, non-invasive debug}.
• Secure bootloader sets them at power-on based on authentication policy.
• Authenticated Debug Access Control (ADAC): challenge-response over DAP using device-specific keys, verified by secure ROM.
• Allowed levels:
  • All debug off → truly unbrickable.
  • NS debug enabled → developers can attach to app firmware.
  • S + NS debug enabled → full access (engineering / RMA only).

TrustZone is only one layer — the SoC bus must also enforce HNONSEC attributes.

• Every AHB-5 transaction carries a HNONSEC bit (0 = Secure access, 1 = NS).
• Slaves may either be TrustZone-aware (check HNONSEC and reject) or TrustZone-oblivious (behind a filter).
• Vendor filter blocks (STM32 GTZC, NXP AHB-RF, Nordic SPU) policy each slave as S-only, NS-only, or either.
• Crypto engine & RNG are usually S-only; user GPIO, UART, timers are NS; flash controller is S-only but the flash contents are split per attribution.

• Draw the 2×2 {S,NS} × {Priv, Unpriv} matrix and list what's banked.
• Explain the difference between SAU, IDAU, and MPU.
• Describe exactly what the SG instruction does and why NSC regions are necessary.
• Explain the integrity signature and what it prevents.
• Walk through a secure boot → TF-M → NS application handoff.
• Compare TrustZone-M vs TrustZone-A (latency, monitor layer, switching model).

• Give an example where TrustZone is the right answer and one where an MPU alone is sufficient.
• List three attacks that TrustZone does not prevent (physical, glitch, side-channel).
• Explain PSA Certified — what does "Level 2" demonstrate?
• Describe BLXNS and when Secure calls back into NS.
• Name the vendor filter blocks that enforce HNONSEC per peripheral on STM32L5 / Nordic / NXP.
• Explain why cmse_nonsecure_entry matters more than just a calling convention.