To avoid potential errors caused by misconfiguration make sure the
conditionally compiled snippets of code surrounded by the
MCUBOOT_DIRECT_XIP_REVERT macro are only used when direct-xip mode
is selected.
Change-Id: I6178d8186a7ca05887bc7590f5fa0c8f83f3d731
Signed-off-by: David Vincze <david.vincze@arm.com>
Multiple image boot support is implemented for direct-xip and ram-load
strategies. Dependency checking is also added, and for ram-load more
executable ram regions can be set.
Wrapper functions are intoduced to all boot strategies.
Change-Id: I59b346277dcb2c17cef4800f1e556b4ea9144845
Signed-off-by: Mark Horvath <mark.horvath@arm.com>
The 'revert' mechanism in direct-xip is similar to the one in swap mode.
It requires the trailer magic to be added to the signed image. When a
reboot happens without the image being confirmed at runtime (without the
image_ok flag being set), the bootloader considers the image faulty and
erases it. After this it will attempt to boot the previous image
instead. The images can also be made permanent (marked as confirmed in
advance) just like in swap mode.
Change-Id: Ibde9361d4a7302dd8efbb277b691b71eca0ca877
Signed-off-by: David Vincze <david.vincze@linaro.org>
Some design.md content is causing build errors when they are included
in a .rst based documentation tree in Sphinx.
Adjust the format to make it work in both systems.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This patch introduces the ram-load mode in addition to the other
upgrade modes (swap strategies, overwrite-only, direct-XIP). When
ram-load is enabled with the MCUBOOT_RAM_LOAD option, mcuboot
selects the newest valid image based on the image version numbers from
the image header, thereafter the selected image loaded to the RAM and
executed from there. Load address is extracted from the image header.
Therefore the images must be linked to the RAM memory region.
The ram-load mode is very similar to the direct-XIP mode, main
difference is to load the newest image to the RAM beforehand the
authentication and execution. Similar to direct-XIP mode either
of the primary and the secondary slots can hold the active image.
Ram-load can be useful in case of a bit more powerful SoC, which
is not constrained in terms of internal RAM. It could be that image
is stored in external and therefore untrusted flash. Loading image
to internal (trusted) RAM is essential from the security point
of view the system. Furthermore execution from internal RAM is much
faster than from external flash.
This patch is based on the RAM_LOADING upgrade strategy which was
first introduced in the Trusted Firmware-M project.
Source TF-M version: TF-Mv1.0.
Change-Id: I95f02ff07c1dee51244ac372284f449c2efab362
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
This patch introduces the direct execute-in-place (XIP) mode in addition
to the other upgrade modes (swap strategies, overwrite-only). When
direct-XIP is enabled with the MCUBOOT_DIRECT_XIP option, mcuboot
selects the newest valid image based on the image version numbers from
the image header, thereafter the selected image runs directly from its
flash partition (slot) instead of moving it. Therefore the images must
be linked to be executed from the given image slot. It means that in
direct-XIP mode either of the primary and the secondary slots can hold
the active image.
This patch is based on the NO_SWAP upgrade strategy which was first
introduced in the Trusted Firmware-M project.
Source TF-M version: TF-Mv1.0.
Change-Id: If584cf01ae5aa7208845f6a6fa206f0595e0e61e
Signed-off-by: David Vincze <david.vincze@linaro.org>
To make contributions easier, place explicit copyrights by the major
contributors, along with an SPDX license identifier. Files that came
from the mynewt project, which was an Apache project will retain the
Apache project license text, although this does not apply to new
contributions, which are being made by individual contributors.
Hopefully, this will keep everyone happy, but allow contributors that
need to add an explicit copyright to have a place they can add that.
Fixes#501
Signed-off-by: David Brown <david.brown@linaro.org>
- Update documentation of 'HW based downgrade prevention'
- Add description for the following features:
MCUBOOT_MEASURED_BOOT
MCUBOOT_DATA_SHARING
MCUBOOT_HW_KEY
Change-Id: If7247e906de3028d44cdd9d14a5004661fb955af
Signed-off-by: David Vincze <david.vincze@linaro.org>
This description is needed to explain why MCUBoot won't
revert a recently performed update.
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
- Add image security counter verification (read security counter value
from the image manifest and compare it against the stored/active
security counter) as an optional part of the image validation process
to prevent the restoration of older, potentially vulnerable images.
- This feature can be enabled with the MCUBOOT_HW_ROLLBACK_PROT option.
- Add security counter interface to MCUBoot. If HW rollback protection
is enabled then the platform must provide a mechanism to store and
read the security counter value in a robust and secure way.
Change-Id: Iee4961c1da5275a98ef17982a65b361370d2a178
Signed-off-by: David Vincze <david.vincze@arm.com>
Depends on 'MCUBOOT_OVERWRITE_ONLY' option since swap info is not protected
by signature
Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
When pages are built from the markdown sources, the html anchors for
titles are automatically added, but no links are inserted in the pages.
This makes it harder to send URLs to sections; one has to browse the
page source to get the correct link. This fixes the issue by adding
links directly to the generated pages.
Signed-off-by: Fabio Utzig <utzig@apache.org>
Updates the protected TLV specification to have their own TLV info struct,
to ease hashing without having to skip parts of the image, while adding the
ability to append new non-protected TLVs.
Signed-off-by: Fabio Utzig <utzig@apache.org>
Since a copy/erase during a swap can result in some number of sectors
erased and copied, which is not necessarily equal to 1, update design
document and bootloader function naming to reflect this fact, by using
the postfix "_region" instead of "_sector" in those cases.
This fixes#541
Signed-off-by: Fabio Utzig <utzig@apache.org>
This patch adds the capability to check image dependencies in case
of multi-image boot. The dependencies are described with a new type
of TLV in the manifest.
Change-Id: If45f81a00d4324c881634f50156f9939e1bf8707
Signed-off-by: David Vincze <david.vincze@arm.com>
This patch adds the capability to handle multiple firmware images,
to update them independently. Also update the design documentation.
It separates the completion of aborted image swap operations and the
update of images even more as these should be happening at different
stages of the boot process according to the design proposal of
the multiple image support:
https://github.com/JuulLabs-OSS/mcuboot/pull/317.
Change-Id: I7eb5f632298bb08c805bfaee0359703b2ae19e9d
Signed-off-by: David Vincze <david.vincze@arm.com>
This patch introduces the BOOT_IMAGE_NUMBER macro and current_image
variable to support multiple updatable images and the associated
extended flash layout.
The FLASH_AREA_IMAGE_* object-like macros are replaced with
function-like ones and therefore some functions have been updated,
because the labels of a switch statement and the initialization
values of objects with static storage duration have to be constant
expressions.
Change-Id: Ib7b26ec3c94233e52db4f97825ddb6a3e55bb1d3
Signed-off-by: David Vincze <david.vincze@arm.com>
Overload the swap_type field in image trailer to store as an addition
the image sequence number. It indicates which image's swap was
interrupted. It is required by multi image boot to determine which
image the trailer belongs to if boot status is found on scratch area
when the swap operation is resumed.
Change-Id: I6820fd8277931aff4f0db408376eae8b42a030ed
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
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>
This change replaces the slot 0/1 terminology with primary/secondary
slot and replaces FLASH_AREA_IMAGE_0/1 with
FLASH_AREA_IMAGE_PRIMARY/SECONDARY. This naming convention may be more
understandable, fits better to MCUs with multiple images and it is an
architecture agnostic alternative as well.
Change-Id: I655a585f6ae023852c671ee6635399efe25209c9
Signed-off-by: David Vincze <david.vincze@arm.com>
Signed-off-by: David Brown <david.brown@linaro.org>
Github pages assumes that links to files using relative
names point to the same location so this should work both
when accessing through the github browser and mcuboot.com
Signed-off-by: Fabio Utzig <utzig@apache.org>
The swap procedure as documented doesn't match the code, and it would
loose the contents of slot1[index] as it's erased before it is copied
anywhere. Also, add the missing word 'to'.
Signed-off-by: Ryan C Johnson <ryan.johnson@flex.com>
The complex blocks are just verbatim, and some of the outline-style
blocks are keps as pre formatted until we decide the right way to format
them.
Signed-off-by: David Brown <david.brown@linaro.org>
David Vincze