bootutil: Store image encrypted in scratch area #1952
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For swap using scratch, the boot_read_image_header routine, responsible for reading the image headers, was always looking for the primary and secondary image's headers at the beginning of respectively the primary and secondary slots, regardless of the current boot status. This means if during a swap-scratch upgrade a reset happens after the sector containing the image header in the primary or secondary slot has been erased, invalid image headers were read since at that time the location of the headers has changed. Currently, this doesn't seem to cause any issue because the swap-scratch algorithm is implemented in such a way the content of the headers is no more necessary when the headers are erased. However, to be able to decrypt the secondary image when copied to the primary slot instead of when copied to the scratch area, properly reading the secondary image's header is required even after it has been erased from the secondary slot. To that end, the boot_read_image_header is modified to determine from the boot status the current location of the image headers and to always read the actual header, no matter the current state of the upgrade process. Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>
Currently, when swap using scratch is used with encrypted images, MCUboot is decrypting the images during the copy from the secondary slot to the scratch area. This means the scratch area contains plaintext image data and therefore that the scratch area must be placed in the MCU's internal flash memory. This commit makes the necessary changes to perform the decryption when copying from the scratch area to the primary slot instead, making possible to place the scratch area in an external flash memory since the scratch area is now encrypted. Note that BOOT_SWAP_SAVE_ENCTLV must be enabled if the scratch area is placed in external flash memory. Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>
When using swap using scratch, the decryption now happens when copying from the scratch area to the primary slot, which means the image is stored encrypted in the scratch area. This commit updates the documentation accordingly. Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>
When 'direct-xip' or 'ram-load' features were enabled, CONFIG_BOOT_SWAP_USING_SCRATCH and MCUBOOT_SWAP_USING_SCRATCH were defined even though swap using scratch wasn't use. This commit fixes the issue. Signed-off-by: Thomas Altenbach <thomas.altenbach@legrand.com>
taltenbach
force-pushed
the
feature/encrypted-scratch
branch
from
bb82c24
to
0653172
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
As discussed on #1942, when swap using scratch is used, the image is currently decrypted while copying from the secondary slot to the scratch area. This means even when
BOOT_SWAP_SAVE_ENCTLVis enabled, the scratch area has to reside in the MCU's internal flash memory.However, being able to place the scratch area in an external flash memory could be valuable since:
This PR proposes changes to perform the decryption while copying from the scratch area to the secondary slot instead, meaning the scratch area does not contain plaintext image data anymore.
The reason why this wasn't performed that way in the first place is probably that it introduces an issue when the device is reset after having erased the first sector of the secondary slot but before having copied it from the scratch area to the primary slot. Indeed, for being able to properly decrypt an image, MCUboot needs the header of that image (cf.
boot_copy_region). This header is located at the beginning of the secondary slot until the first sector of the secondary slot is processed. At this time:If a reset occurs after step 1, the secondary image's header might not be located anymore in the secondary slot but is still needed when using encrypted scratch since the first segment of the image has to be decrypted during step 3. However, when using swap using scratch, MCUboot is currently always looking for the primary and secondary image's headers in respectively the primary and secondary slots, regardless of the current boot status (cf.
boot_read_image_header). Therefore, this MR also modifies theboot_read_image_headerroutine to properly load the image headers, according to the current progress of the upgrade.Tests
enc-x25519,enc-x25519 multiimage,enc-x25519 overwrite-only,enc-x25519 ram-load,enc-x25519 swap-moveanddirect-xip.