Fixed security counter overflow detected to late

[ahasztag]

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]

Note: I have not added nrf squash! as there does not seem to be a noup commit this could be reasonably squashed with. The only noup which changes code related to the security counter seems to be bf14385 but the issue it addresses is unrelated.

Also, I wasn't able to find a way to put this fix upstream. The fix needs a function like the added boot_nv_security_counter_is_update_possible which is platform specific and needs to be placed in NCS like the other security counter related platform functions. Adding a call to this function would break any non-NCS platforms. If you think this fix should go upstream please let me know if there is a way to address boot_nv_security_counter_is_update_possible being undefined for non-NCS platforms

[nordicjm]

Note: I have not added nrf squash! as there does not seem to be a noup commit this could be reasonably squashed with. The only noup which changes code related to the security counter seems to be bf14385 but the issue it addresses is unrelated.

Also, I wasn't able to find a way to put this fix upstream. The fix needs a function like the added boot_nv_security_counter_is_update_possible which is platform specific and needs to be placed in NCS like the other security counter related platform functions. Adding a call to this function would break any non-NCS platforms. If you think this fix should go upstream please let me know if there is a way to address boot_nv_security_counter_is_update_possible being undefined for non-NCS platforms

Use a hook

[ahasztag]

Note: I have not added nrf squash! as there does not seem to be a noup commit this could be reasonably squashed with. The only noup which changes code related to the security counter seems to be bf14385 but the issue it addresses is unrelated.
Also, I wasn't able to find a way to put this fix upstream. The fix needs a function like the added boot_nv_security_counter_is_update_possible which is platform specific and needs to be placed in NCS like the other security counter related platform functions. Adding a call to this function would break any non-NCS platforms. If you think this fix should go upstream please let me know if there is a way to address boot_nv_security_counter_is_update_possible being undefined for non-NCS platforms

Use a hook

The reason I was hesitant to use a hook is that all other functions from https://github.com/nrfconnect/sdk-mcuboot/blob/main/boot/bootutil/include/bootutil/security_cnt.h are not hooks although they are exactly part of the same functionality and also defined in NCS.

If boot_nv_security_counter_is_update_possible would be a hook this would be inconsistent.

In this case should I:

1. Accept the inconsistency for this single function
2. Rewrite other functions from security_cnt.h to also be hooks?

[nvlsianpu]

I would update the upstream API. Untill that it can be [nrf noup] patch. rationale:

• IMO this is for implementing proper PSA defined behavior. If security counter can't be increase - the bootloader should take respective action for that case,

[sonarqubecloud]

Quality Gate failed

Failed conditions
D Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE