8.4.4.1 IRT Partition

A designated portion of the user program is used for the IRT partition. The IRT Flash space is specified using Flash protection regions. One or more permanent IRT regions may be created for firmware, data and cryptographic keys. Once IRT is enabled, IRT regions are only accessible during IRT execution except for debug access when authorized by the IRT firmware. An IRT region may have write permissions disabled, making it immutable (generally for firmware) or have write permissions enabled (generally for configuration data and keys) and allowing it to be updated.

IRT is enabled by the IRT (FIRT[0]) Configuration bit in the UCB area. By default (erased UCB), IRT is disabled. When IRT is disabled, IRT regions (if any) are not protected and are accessible to firmware outside the IRT partition. IRT regions are only truly permanent once either the UCB erase-protect and/or UCB write-protect words are programmed. For development, the UCB erase and write-protect words may be left unprogrammed. When IRT is enabled, a permanent immutable protection region with IRT firmware must be configured for the beginning of user program Flash. This region is functionally the boot ROM for the device and may be either an OTP region or IRT region with write permission disabled.

OTP region firmware can be shared between the IRT and other firmware components. IRT firmware execution starts after resetting into Mission mode. IRT execution ends when the IRT firmware sets the DONE (IRTCTRL[2]) bit and there is a subsequent instruction fetch from user program Flash not within an IRT region. This includes an attempted instruction fetch that has an error, such as an access privilege violation or an uncorrectable bit error.

IRT firmware may set the DONE bit (IRTCTRL[2]) and transfer control to the application (non-secure) code while executing from an IRT region. IRT firmware must ensure that the application code is not prefetched before the DONE bit is set. This ensures that the start of the application code is fetched after the DONE bit is set, disabling the IRT partition before the application code can execute. This requirement can be met by having at least 32 bytes of separation between the end of IRT firmware and the start of application firmware. IRT firmware must ensure the application start address is in user program Flash and not within an IRT region. For the IRT partition to be secured, either the UCB write-protect word or the UCB erase-protect word must be programmed. For development, the UCB erase and write-protect words may be left unprogrammed. Permission to access the IRT partition is indicated by the partition lock PLCK (IRTCTRL[4]) bit. Partition access is allowed (PLCK bit = ‘0’) when IRT is disabled, during IRT execution and for debug access when the DBG (IRTCTRL<1>) bit is set. Otherwise, partition access is disabled (PLCK bit = ‘1’).

The IRT partition implementation is based on the principle of temporal isolation. Since IRT firmware is the first firmware to execute after Reset, it controls execution of other firmware components. Sensitive IRT data is cleared from registers and RAM before executing any application (non-secure firmware). Likewise, the IRT partition is disabled (PLCK bit = ‘1’) before executing the application (non-secure firmware), preventing it from accessing or corrupting IRT Flash regions. If IRT firmware code needs to be protected from access by non-security firmware, the instruction cache should be invalidated and disabled before transferring control to the application firmware. The IVT base address should be set to application space before attempting to transfer control to the application firmware. This ensures that application firmware exceptions, starting with the first application code instruction, can be handled by application trap handlers.

Secure debug must be enabled and external access must be disabled (EAA (IRTCTRL[0]) bit = ‘0’) for the IRT partition to be fully protected from the external access. When secure debug is not enabled or when it is enabled but external access is allowed (EAA bit = ‘1’), the external access to internal registers and RAM values is possible via ICSP interface. A properly timed Reset during IRT execution may reveal sensitive information in RAM and registers that retain their state through the Reset.

IRT partition access may be extended to updatable root of trust firmware components. One or more updatable components (stages) are authenticated directly by IRT firmware or indirectly with the chain of trust process previously described. The updatable root of trust components executes with the IRT partition enabled. The IRT partition is locked by the IRT or updatable root of trust firmware by setting the DONE bit before starting execution of the application (non-secure code). Alternatively, updatable root of trust components may have an independent security partition. In this case, the IRT disables the IRT partition before transferring control to an updatable root of trust component in a non-IRT region. A separate (non-IRT) protection region can be set up for the updatable root of trust components to store cryptographic keys and configuration data. Access to this region is disabled before transferring control to the application (non-secure firmware). Unlike the IRT partition, this partition is erased on a chip erase and can be accessed by debug without a specific authorization. IRT firmware may implement a security life cycle state using IRT region storage. This is separate from the higher-level device life cycle state controlled by the UCB write-protect word. Additionally, IRT firmware may implement nonvolatile secure debug Configuration options.

IRT partition memory is not erased on a chip erase, and debug access to IRT memory is controlled by IRT firmware.