Desktop version

Home arrow Computer Science arrow A Practical Guide to TPM 2.0

System-Wide Security

ARM often describes TrustZone as system security, [1] but what does that mean? In this case, the system refers to everything in the SoC connected to the central processor by the AMBA®[2] AXI™ bus. [3] So in addition to providing simple memory and process separation for the two-worlds model, it also extends protection to data and interrupts handled by peripherals. [4]

Bus masters can be marked secure, meaning they're controlled by software running in the SWd, or insecure, meaning they can be accessed by either world. [5]When a secure peripheral interacts with the system, nothing in the untrusted world can see it or directly interfere with it: not even kernel code. Typical use cases for such a thing would be a Secure Element chip (cryptographic key storage device not accessible to normal code) or a touchscreen UI (trusted user interaction).

Implementation of TrustZone

The successful implementation of TrustZone in an SoC and system depends on many aspects of design but there are three major pieces to consider: the NS bit, the Monitor, and secure interrupt handling.

The NS bit

The NS (or 'Non-Secure') bit is the central manifestation of TrustZone in the ARM processor architecture. It's a control signal that accompanies all read and write transactions to system bus masters, including memory devices. As the name suggests, the NS bit must be set low in order to access SWd resources.

To understand how something so simple can reliably achieve world separation, it's sometimes useful to think of NS as an extra address bit[6] that effectively partitions the memory space into two parallel logical regions: 32-bit space plus NS. This analogy makes TrustZone isolation and error behavior intuitive: attempts from NWd to access SWd memory will fail, even if it knows the exact 32-bit address it wishes to attack, because the 33rd bit is different and so doesn't map to the desired memory location.

Clearly the security of the system would break down if NWd code were somehow able to set the NS bit in resource requests directly, so it's set, maintained, and checked by processor registers and bus components such as the memory controller and address space controller. Returning to the 33rd bit analogy for a moment, code makes a normal 32-bit request; and the processor hardware, knowing that the code is executing in insecure mode, adds NS=1 to the transaction.

  • [1] arm.com/products/processors/technologies/trustzone/index.php.
  • [2] Advanced Microcontroller Bus Architecture. See en.wikipedia.org/wiki/Advanced_ Microcontroller_Bus_Architecture for further definitions and acronyms.
  • [3] Technical note: Only AXI masters are able to correctly preserve TrustZone signals. Work is required to securely integrate AHB™ or APB™ devices
  • [4] Again, peripheral here refers to masters connected directly to the AMBA AXI bus inside the SoC. It doesn't mean external devices like VDUs or printers.
  • [5] Remember the asymmetrical nature of TrustZone: SWd can access everything.
  • [6] The “33rd (or 41st or 65th) address bit” analogy can fail when you look at certain deep details, but it's close enough to be useful.
 
Found a mistake? Please highlight the word and press Shift + Enter  
< Prev   CONTENTS   Next >

Related topics