Security Mechanism Upon Boot

In addition to the basic hardware facilities, RSL15 also holds the secure boot and secure debug implementation in ROM to prevent corruption, guaranteeing that the RoT is verified on boot.

The secure keys and assets required to manage the secure boot process are held in NVM memory in a manner that ensures any corruption is detected during the power-up sequence.

Any corruption detected in the NVM renders the device invalid and prevents any application code from executing, while also restricting access to the device from the debug port.

There are three boot paths:

  1. Cold boot: The system is coming up from full reset and Root of Trust is evaluated if needed.
  2. Warm boot: The system is coming up from a wake state, but the Root of Trust has already been evaluated, so the system does not re-evaluate it. This is sometimes referred to as wakeup from flash. For a successful warm boot without retention (ACS_VDDRET_CTRL_VDDCRET_DISABLE and/or ACS_VDDRET_CTRL_VDDMRET_DISABLE field set in the ACS_VDDRET_CTRL), make sure that the Arm CryptoCell-312 is always enabled, which is the default.
  3. Custom boot: The system is waking up from sleep and uses a RAM vector to restart. Again, the Root of trust has already been evaluated so this is not redone.

Therefore, each time the Life Cycle State changes, a cold boot (full reset) is required afterward for it to take effect. For more information on the boot paths themselves, refer to the ROM Initialization Sequence section of the RSL15 Firmware Reference

A secure bootloader should be used to perform software image validation and authentication during system boot and on updates. An example is provided in the RSL15 sample application collection and is described in the Secure Bootloader Usage guide.