boot: bootutil: Fix security counter updated before revert after resuming upgrade #2282
Conversation
This file contains hidden or 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
When an upgrade is performed, the security counter must only be updated after the upgrade has been confirmed, to make possible to rollback if needed. To that end, the security counter was only updated for a given image if the swap type is BOOT_SWAP_TYPE_NONE, meaning in most cases that no update has been performed by MCUboot at this run. However, the swap type is also set to BOOT_SWAP_TYPE_NONE after an interrupted upgrade is completed, so at the time boot_update_hw_rollback_protection is called, having a "none" swap type doesn't guarantee that no upgrade is waiting for confirmation. This means MCUboot was wrongly updating the security counter immediately after the completion of a resumed upgrade, preventing any rollback in that case. Instead, the boot_update_hw_rollback_protection now checks the trailer of the primary image to determine if the security counter has to be updated. The update occurs only if the trailer is empty (no update has ever been made) or if the "image-ok" flag is set (the image has been confirmed). Signed-off-by: Thomas Altenbach <[email protected]>
When testing upgrades, the simulator was always using two images having the same security counter. This was preventing to test that the security counters are updated at the right time in the scenarios where a revert is possible. The upgrade image is now generated with a higher security counter than the original image, enabling to detect e.g. the issue fixed by the previous commit. Signed-off-by: Thomas Altenbach <[email protected]>
d3zd3z
approved these changes
May 1, 2025
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.
This PR fixes an issue that was preventing an interrupted then resumed upgrade to be reverted when the hardware rollback protection is enabled and the swap-scratch, swap-move or swap-offset strategy is used.
After a "test" upgrade has been performed, the security counter of every image must not be updated immediately to be able to roll back in case the upgrade is not confirmed. To that end, the
boot_update_hw_rollback_protectionroutine, called just before exiting MCUboot, was checking the swap type of the image and updating the security counter only if the swap type was none, with the assumption that it implies no upgrade has been performed by MCUboot. This was working properly in the nominal case, when the upgrades are not interrupted, however this assumption is false if MCUboot has just resumed an upgrade after a power cycle because in that case the swap type is set to none after the end of the upgrade process:mcuboot/boot/bootutil/src/loader.c
Lines 2251 to 2252 in 8131548
So, let's suppose an image A with a security counter N is upgraded, in "test" mode, to an image B with a security counter M > N:
This was not detected by the tests since in the simulator the upgrades were performed with images having the same security counter value. In addition to fixing the issue, this MR also updates the simulator to use images with different security counter values, enabling to catch such kind of bugs.