Updating the Secure Bootloader Itself

Updating the secure bootloader itself is much the same as updating a secure application. It uses the same function but with a different image. Flags are used for differentiation between a basic bootloader and a secure bootloader to determine the image size needed, since the secure bootloader uses more memory.

To prepare a secure bootloader, take the following steps:

  • Ensure that you have, or make sure to create, all the necessary keys and key certificates. See the RSL15 Security User's Guide for details on creating secure applications.
  • Create a content certificate based on the key certificates.
  • Sign the image using the created certificates.

The new bootloader must be fully validated prior to switching to it, so that a complete copy is held in memory.

IMPORTANT: When updating a bootloader via the secure bootloader download mechanisms, care must be taken to ensure that the image being loaded is correct and that the update process is allowed to run to completion.

The update process is in two parts:

  1. Initially, the new application or bootloader is stored in the download area of flash memory.
  2. When the system is reset, the secure bootloader verifies and, if necessary, authenticates the image in the download area. If these checks pass, the image is copied to the secure bootloader area of flash memory.

This copying from the download area to the bootloader area by definition corrupts the bootloader at some point before the full image has been copied. If the power is lost during this stage, the system cannot recover, requiring a new bootloader to be loaded using the debug port.

Similarly, if the application or bootloader that has been loaded is faulty or is not a valid bootloader, this renders the secure bootloader unable to function.

In the current design there is no way around this issue; however, there are several mitigation strategies that can be employed to provide a more robust solution. These can include some combination of the following:

  • Store a redundant copy of the bootloader, which can be reverted to in case of major system failure.
    • This redundant copy can have limited verification and authentication capabilities if that meets the customer needs.
  • Partition the bootloader such that it has a mutable and immutable component. The immutable component could be the part that handles the copying from the download area to the secure bootloader area.
  • Disable the ability to update the bootloader itself except under very specific and controlled circumstances where the user cannot unintentionally render the device completely inoperable.