RAM Load and Direct XIP firmware downgrade capability #2225
Conversation
…/direct XIP rather than relying on version number comparison This commit adds new configuration option MCUBOOT_RAM_LOAD_USE_UPDATE_COUNTER (for use with MCUBOOT_RAM_LOAD) and MCUBOOT_DIRECT_XIP_USE_UPDATE_COUNTER (for use with MCUBOOT_DIRECT_XIP). By default, in RAM load/direct XIP modes, the slot that will boot is the one having the higher version number. This means it is not possible to downgrade to earlier image versions. By configuring one of the new *_USE_UPDATE_COUNTER options, a counter value in the image trailer will be consulted first to determine which image to boot, falling back to comparing the image version if the trailer is missing or there is a tie. During firmware update, the application code should read the counter value for the running image, increment it, and store that value in the image trailer of the updated slot. The counter is stored in the 'swap size' field which is not used by the RAM load/direct XIP modes.
There was a problem hiding this comment.
I don't see the point in this, the whole point in the version is to boot the newest version. If you want something different, you should utilise the boot hooks to select the image to boot and return the other image as empty. Also this is completely bypassable by any rogue code so your security is nil
|
That may be what is appropriate for your use case, but for me it is an absolute requirement that it is possible to downgrade the firmware. The swap upgrade modes allow downgrades to happen, so this is just an extension of that to RAM load/direct XIP modes. Security is not "nil", because the image still has to be signed. If downgrade is not desirable in a particular application, then just leave the feature off. If my system is running "rogue code" then it is already compromised at that point. I would also add that returning one image as empty is not equivalent to this because my implementation allows falling back to the other image if the selected one is not bootable (e.g. signature check fails). This is necessary because when the application installs a new image to the non-running slot, it cannot know whether it will pass the signature check etc. If we only allowed mcuboot to boot from that new image, installing an invalid update file would brick the device. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
I still think this is relevant. We are using this code. It has not yet had any serious review beyond attacking comments that fail to take into account the context. |
2 participants
This PR adds new configuration options MCUBOOT_RAM_LOAD_USE_UPDATE_COUNTER (for use with MCUBOOT_RAM_LOAD) and MCUBOOT_DIRECT_XIP_USE_UPDATE_COUNTER (for use with MCUBOOT_DIRECT_XIP).
By default, in RAM load/direct XIP modes, the slot that will boot is the one having the higher version number. This means it is not possible to downgrade to earlier image versions. By configuring one of the new *_USE_UPDATE_COUNTER options, a counter value in the image trailer will be consulted first to determine which image to boot, falling back to comparing the image version if the trailer is missing or there is a tie.
During firmware update, the application code should read the counter value for the running image, increment it, and store that value in the image trailer of the updated slot. The counter is stored in the 'swap size' field which is not used by the RAM load/direct XIP modes.