ARM TrustZone has been a feature of the ARM processor architecture since 2002 and first appeared in real processors—specifically the 1176JZF™—shortly afterward in 2003. Since then, not much has changed with TrustZone itself, but many additional features, technologies and use cases have grown up around it.
It's not uncommon for TrustZone and Intel TXT to be compared and/or lumped together as each architecture's 'security extension', but below a rather superficial level the two aren't particularly similar and such comparison doesn't aid understanding. This section explores a little of what TrustZone is, how it works, and how it relates to TPM technology. At a high level, TrustZone provides a safe place for a software TPM implementation to execute.
At the simplest level, TrustZone provides a facility to create a virtual second processor inside a single system on chip (SoC). Through the implementation of a special operating mode, the SoC is able to create two separate parallel software stacks (or 'worlds'): the Normal World (NWd), which runs the main OS and user interface, and the Secure World (SWd), which runs a trusted software stack implementing security features. The two worlds are kept separate by the SoC hardware so that the main OS can't interfere with programs or data in the SWd. This enables users to retain trust in the integrity and confidentiality of SWd data even when they can't trust the state of the device as a whole.
Typically, a system designer doesn't want to impact the user experience of the device and so keeps the SWd hidden away, often using it to create a virtual security processor that the main OS calls when needed. For the most part, this idea of a virtual security processor is useful, but one very important detail must be made clear: while the SWd is completely protected from direct access by untrusted NWd code, the reverse isn't true.
SWd code can, in principle, access any memory or device in the system. This asymmetric setup has many positive implications—high-speed data transfer and the ability to integrity-check NWd memory among them—but it also gives the SWd control over the entire device, not just the security module it implements.
-  Note a slight problem of terminology here. The original naming of these architectural features follows a secure vs. non-secure theme, but as we all know, there is no such thing as absolute security: every protection system has its limits. In recent years, this terminology has given way to the more subjective trusted vs. normal concept, but remnants of the secure naming remain in the names of various components. This chapter uses the (non-)secure and (un-)trusted terms interchangeably.