Fix double swap on interrupted revert

This fixes #480.

When mcuboot rewrites image trailers during a swap, some information is
lost.  If a reset occurs before the swap completes, mcuboot may not be
able to determine what which swap type to resume upon startup.
Specifically, if a "revert" swap gets interupted, mcuboot will perform
an extraneous swap on the subsequent boot.  See
https://github.com/JuulLabs-OSS/mcuboot/issues/480 for details.

This commit adds an additional field to the image trailer: `swap-type`.
The new trailer structure is illustrated below:

```
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                                                               ~
    ~    Swap status (BOOT_MAX_IMG_SECTORS * min-write-size * 3)    ~
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                 Encryption key 0 (16 octets) [*]              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                 Encryption key 1 (16 octets) [*]              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Swap size           |    0xff padding (4 octets)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Swap type   |           0xff padding (7 octets)             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Copy done   |           0xff padding (7 octets)             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Image OK    |           0xff padding (7 octets)             ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       MAGIC (16 octets)                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

The `swap-type` field contains one of the `BOOT_SWAP_TYPE_[...]` constants.
Every time a trailer is written, this field is written along with it.
When resuming an interrupted swap, mcuboot uses this field alone to
determine the type of swap being resumed. For new swap operations
(non-resume case), this field is not read at all; instead, mcuboot
consults the `boot_swap_tables` array to determine the swap operation to
perform (as it did prior to this commit).

Some additional changes were necessary to make all the simulated unit
tests pass:

* Before initiating a new swap operation, always write the image trailer
to the scratch area.  This step allows mcuboot to persist the
`swap-type` field somewhere before erasing the trailer in the primary
slot.  If a reset occurs immediately after the erase, mcuboot recovers
by using the trailer in the scratch area.

* Related to the above: if the scratch area is being used to hold status
bytes (because there are no spare sectors in the primary slot), erase
the scratch area immediately after the trailer gets written to the
primary slot.  This eliminates ambiguity regarding the location of the
current trailer in case a reset occurs shortly afterwards.

Signed-off-by: Christopher Collins <ccollins@apache.org>
6 files changed
tree: cb404a2ba437a4c987a32ef4903f6b7831e71dee
  1. boot/
  2. ci/
  3. docs/
  4. ext/
  5. ptest/
  6. samples/
  7. scripts/
  8. sim/
  9. testplan/
  10. .gitignore
  11. .gitmodules
  12. .travis.yml
  13. enc-aes128kw.b64
  14. enc-rsa2048-priv.pem
  15. enc-rsa2048-pub.pem
  16. LICENSE
  17. NOTICE
  18. project.yml
  19. README.md
  20. repository.yml
  21. root-ec-p256-pkcs8.pem
  22. root-ec-p256.pem
  23. root-rsa-2048.pem
  24. root-rsa-3072.pem
  25. version.yml
README.md

mcuboot

Coverity Scan Build Status Build/Test

This is mcuboot, version 1.3.0

MCUboot is a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade.

MCUboot is operating system and hardware independent and relies on hardware porting layers from the operating system it works with. Currently, mcuboot works with both the Apache Mynewt, and Zephyr operating systems, but more ports are planned in the future. RIOT is currently supported as a boot target with a complete port planned.

Using MCUboot

Instructions for different operating systems can be found here:

Roadmap

The issues being planned and worked on are tracked using GitHub issues. To participate please visit:

MCUBoot GitHub Issues

Issues were previously tracked on MCUboot JIRA , but it is now deprecated.

Browsing

Information and documentation on the bootloader are stored within the source.

It was previously also documented on confluence: MCUBoot Confluence however, it is now deprecated and not currently maintained

For more information in the source, here are some pointers:

  • boot/bootutil: The core of the bootloader itself.
  • boot/boot_serial: Support for serial upgrade within the bootloader itself.
  • boot/zephyr: Port of the bootloader to Zephyr
  • boot/mynewt: Mynewt bootloader app
  • imgtool: A tool to securely sign firmware images for booting by mcuboot.
  • sim: A bootloader simulator for testing and regression

Joining

Developers welcome!