boot: avoid increasing rollback counter during RAM load FW update

[meremST]

When MCUBOOT_RAM_LOAD_REVERT is enabled, the rollback counter must not be incremented until image_ok is set. Otherwise, in the event of a revert, the boot process may become bricked.

[d3zd3z]

Unfortunately, I think this makes an existing vulnerability window happen in even more cases. The problem is that we can't wait until the next reboot to update the counter, or this can be tricked by not allowing the device to boot a second time after each update.

I think the right fix is to, for test boots, to have the security counter updated as part of "confirmation", not part of the normal boot. However, there are challenges to doing this, so I'm not quite sure what the right solution is.

[meremST]

Unfortunately, I think this makes an existing vulnerability window happen in even more cases. The problem is that we can't wait until the next reboot to update the counter, or this can be tricked by not allowing the device to boot a second time after each update.

I think the right fix is to, for test boots, to have the security counter updated as part of "confirmation", not part of the normal boot. However, there are challenges to doing this, so I'm not quite sure what the right solution is.

Hello,

I think I see the vulnerability you mention here, but why is the RAM load impacted while direct XIP is not? This is nonetheless an issue, as in the case of a failed update, the platform will be bricked.

If I understand your "confirmation" proposal correctly, could we implement a sort of counter decrease procedure inside boot_select_or_erase in case of a revert?

At some point in the FWU process, the candidate image must be tested, and it is at that moment that the image_ok bit will be updated in the TLV. Maybe the solution is to force a system reset during the image acceptance process.