Firmware Update

Status: Pre-RFC

Overview

The purpose of this document is to capture the process by which Tock will perform a complete in-place B-slot update of the running firmware and request that the ROM/ROM_EXT code boot into it.

Note: For certification reasons this document does not discuss detailed guidance for encrypted updates. Additional implementation details on both regular and encrypted updates to follow when possible.

Update Process

  1. A firmware update is initiated by a process external to the device.
    1. The system negotiates the parameters of the update:
      1. The system’s availability for an update.
      2. Which slot the update must be built for, if the update requires a specific memory location (such as non relocatable monoliths).
      3. Which signature the update must be signed with in order to boot.
      4. The size of the update blocks. These should ideally be the same size as native flash pages.
      5. The total size of the update payload, in order to set boundaries on which the update can be performed.
  2. The system unlocks the flash protection for the bounds of the B-slot.
  3. For each block of the pending firmware update:
    1. The system erases the flash page at the destination address for the block.
    2. The system receives the block and writes it immediately to its destination address in flash. Blocks will need to be buffered given the speed of a flash write.
    3. Once written, the block is hashed and compared against the hash of the buffered block. This ensures that every flash write is complete and successful.
      1. If the hash doesn’t match the hash of the buffered block, repeat the flash erase and write cycle.
      2. If the erase/flash cycle fails three times declare complete failure.
  4. Issue a warning to the running applications that the system will be resetting.
  5. Write a Boot Services request block into persistent RAM:
    1. Indicate the new firmware version slot to be booted.
    2. Indicate the retry policy to use when booting it.
  6. Restart the system with a Boot Services cause set.
  7. System follows the normal Secure Boot path into the new firmware image.