Skip to content

bootutil: Fixed security counter overflow detected to late #2420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 14, 2025

Conversation

ahasztag
Copy link
Contributor

This commit fixes the issue, occuring when the maximum amount of security counter updates has been reached.

This fact was only detected after a permament update already happened - the updated firmware was unable to boot, as it failed when trying to update the security counter after the permament swap.

This commit adds the check if the security counter can be updated (i. e. free security counter slots are still available) before the swap is performed, fixing the issue.

@ahasztag ahasztag force-pushed the fix_security_counter_update_oob branch from 7b100f8 to cad5f2b Compare August 11, 2025 12:20
@@ -437,6 +437,18 @@ bootutil_img_validate(struct boot_loader_state *state,
goto out;
}

#if MCUBOOT_HW_ROLLBACK_PROT_COUNTER_LIMITED
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#if MCUBOOT_HW_ROLLBACK_PROT_COUNTER_LIMITED
#ifdef MCUBOOT_HW_ROLLBACK_PROT_COUNTER_LIMITED

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@ahasztag ahasztag force-pushed the fix_security_counter_update_oob branch from cad5f2b to ecc51f2 Compare August 11, 2025 12:24
*
* @return FIH_SUCCESS if update is possible; FIH_FAILURE otherwise
*/
fih_ret boot_nv_security_counter_is_update_possible(void);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(from the previous comment) this should have the image id I think because there might be multiple counters with different limits

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint32_t image_id,

Copy link
Contributor Author

@ahasztag ahasztag Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, done; I also added img_security_cnt, the new security counter value - in case the security counter was not only limited by the number of updates, but also by the value of the counter itself (which is a situation described in the psa boot guide)

@ahasztag ahasztag force-pushed the fix_security_counter_update_oob branch 2 times, most recently from f8e13fb to 0f742d1 Compare August 12, 2025 10:17
This commit fixes the issue, occuring when the maximum amount of
security counter updates has been reached.

This fact was only detected after a permament update already
happened - the updated firmware was unable to boot, as it
failed when trying to update the security counter after
the permament swap.

This commit adds the check if the security counter can be
updated (i. e. free security counter slots are still available)
before the swap is performed, fixing the issue.

Signed-off-by: Artur Hadasz <artur.hadasz@nordicsemi.no>
@ahasztag ahasztag force-pushed the fix_security_counter_update_oob branch from 0f742d1 to 2eb2959 Compare August 14, 2025 08:11
@de-nordic de-nordic merged commit fe8f9fc into mcu-tools:main Aug 14, 2025
58 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants