TrustZone is a feature present in many modern ARM processors
such as the Cortex-A8 or A9. Essentially, it provides an additional ‘world’ for execution, partitioning the processor into two effective
virtual ones. The ‘secure’ state has banked copies of most of the system registers (for example,
TTBR0/translation-table base register 0)
and implements the monitor mode versus the ‘non-secure’ mode that does not.
TrustZone isn’t simply a processor feature, it’s a complete collection of technologies that also include the BP147 AMBA Protection Controller and the TZASC. Using these technologies properly allows you to implement a ‘secure’ world, seperated from the normal address bus and ‘non-secure’ applications.
This post will mainly be concerned about how one can implement TrustZone on a machine with security extensions. The example used here will be an iPhone 4, however, any device that boots into a ‘secure’ state can be switched over to a ‘non-secure’ state very easily.
The ‘secure’ world has its own set of banked registers, including its own
spsr, much like other ARM modes. However, the biggest
difference between the two worlds lie in peripheral accesses. A peripheral can check for the
AxPROT signal and yield an error/return 0 if
the processor is not in a secure state. System page tables can also mark a region of memory as ‘secure’ or ‘non-secure’ as necessary, however, this
relies on the trusted OS only being able to manage the system page tables. Additionally, certain system coprocessors are unavailable in non-secure
SCR for example), writing/reading from them will result in an undefined instruction error.
The processor always will boot in the most secure state (
SCR = 0), along with all of its peripherals on reset. Returning to the ‘non-secure’ world
can be done by writing the
SCR.NS bit. A switch between worlds is effective immediately. Returning back to the ‘secure’ world is done using the
If you’re making a ‘trusted OS’, please make sure to properly harden your
SMC handlers and prevent register/information leaks as much as you can. Don’t
be a Motorola.
Setting up TrustZone
SMC instruction depends on the MVBAR being set to a valid MVA, if there are no instructions present at the specified address,
pc will be redirected
there anyhow. The MVBAR format is very similar to the standard ARM vector table, however, the
SVC handler is replaced with the
SMC handler. It’s pretty
EnterARM(start) b _reset_secure_tramp /* Reset vector. */ nop /* Unused, undefined. */ b _reset_secure_sp_tramp /* SMC instruction handler. */ nop /* Unused, prefetch abort. */ nop /* Unused, data abort. */ nop /* Unused, address line exception. */ nop /* Unused, IRQ. */ nop /* Unused, FIQ. */
SMC can then be used in a privileged context to enter monitor mode. It forms the communication link between both worlds. The
SMC exception handler
works very much like a standard ARM exception handler. You must use
rfe or somesuch to return from the exception state.
(Please do note that the TTBR used for address translation in secure mode will be the banked copy of the register.)
Since the iPhone 4 is one of those platforms that implement TrustZone, but also reset in secure mode, we can use it as a very ‘cheap’ development platform to create a simple TrustZone bootloader.
A terribad sample implementation of a stubloader is available here.
iBoot seems to run fine with
SCR.NS=1 based on what I’ve tested. Your mileage may vary.
(There’s also a QEMU fork with TrustZone support available here, however, it is not perfect.)Share