ARM TrustZone and Trusted Execution Environments
ARM TrustZone splits a single processor into two worlds: a normal world running the main OS and a secure world holding keys and sensitive logic. It is the foundation of mobile and embedded Trusted Execution Environments. Done well it is a strong boundary; done carelessly it adds a high-privilege attack surface. Here is how it works and where it breaks.
Two Worlds on One Chip
TrustZone partitions memory, peripherals, and CPU state into secure and normal. The normal world cannot read secure memory, but it can ask the secure world to act through a Secure Monitor Call. That call boundary is the entire security model, and every parameter crossing it is untrusted input to privileged code.
The Call Boundary
A normal-world client invokes a trusted application by trapping into the secure monitor:
# secure-world bring-up, seen from the kernel log
dmesg | grep -i optee
optee: probing for conduit method optee: revision 3.19 (a1b2c3d4) optee: initialized driver
Where the Boundary Fails
Most TrustZone vulnerabilities are not breaks of the isolation itself; they are bugs in the trusted code that trusts the wrong input. A trusted application that dereferences a normal-world pointer without validating it, or that mishandles a shared buffer, hands the attacker code execution at the highest privilege level on the chip.
Three TEE Pitfalls
The recurring problems in TrustZone-based designs:
Building a Sound TEE
Keep the secure world small so the trusted computing base is auditable, validate every argument and every pointer crossing the boundary, copy shared buffers into secure memory before use, and treat the normal world as fully hostile. The smaller and more paranoid the secure world, the stronger the guarantee.
Where This Fits
Reviewing the secure-world attack surface and the SMC boundary is part of a deep product security assessment on TrustZone-based devices. That review is the kind of work we do at Berkner Tech.