Overwrite only with downgrade prevention problem(?)

[kasjer]

I'm not sure if this is by design but when downgrade prevention with version number is used and overwrite only method is chosen,
having exact same version in slot1 will result in erasing slot0 and writing it anew.

It would seem that changing condition:

        rc = boot_version_cmp(
                &boot_img_hdr(state, BOOT_SECONDARY_SLOT)->ih_ver,
                &boot_img_hdr(state, BOOT_PRIMARY_SLOT)->ih_ver);
        if (rc < 0 && boot_check_header_erased(state, BOOT_PRIMARY_SLOT)) {

to

        rc = boot_version_cmp(
                &boot_img_hdr(state, BOOT_SECONDARY_SLOT)->ih_ver,
                &boot_img_hdr(state, BOOT_PRIMARY_SLOT)->ih_ver);
        if (rc <= 0 && boot_check_header_erased(state, BOOT_PRIMARY_SLOT)) {

would not be a bad idea.

[Laczen]

@kasjer , i think this is by design to allow a newer build hut with the same version to overwrite the older. This also means that the same image will overwrite the existing.
If this method would not be applied you would have to increase your version each time during development and quickly there would be no version left.

[kasjer]

@Laczen I would enable downgrade prevention only for production builds, during development it's more likely that image is transfer to slot 0 directly or downgrade prevention is not enabled.
The other way this problem could be approached is if MCUboot could check hash of current image compare it with image that is in slot 1 and if they are same skip overwrite to optimize things.

I could propose PR that would make optionally downgrade prevention based on strict version comparison.
Do you think it's worth to try?

[Laczen]

@kasjer, imho it is never a good idea to have a difference between a production build bootloader and a development bootloader. This will create an opportunity to miss an error by development that will be present in the field.
Comparing the image hash would be a possibility, but what about data that would not be part of the image.
The downgrade protection is a lot more complex than how it is handled in mcuboot. In the suit method for updates this is handled better: An upgrade has a manifest that has a strictly increasing number, this number has nothing to do with the image version and thus it is also allowed to downgrade image versions. In mcuboot there is no manifest version and this property is reflected in the image version. This has some bad consequences that we have to live with, the solution not to do strict version comparison is a result of that. The disadvantage is that the same image is allowed to be written to flash multiple times.
I don't think this can easily be solved and in the end some kind of manifest version that is separated from the image version will be required.

[github-actions]

This issue 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 issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[kasjer]

@Laczen Her is my scenario:
Device that can be upgraded from SD card. SD card is visible in MCUboot as flash area. Once device is rebooted with SD card with newer image present, overwrite upgrade is performed. Image from SD card is NOT erased so it can be used on other devices later on.
If card is left in the SD card slot and device reboots again unnecessary upgrade is performed.
I can write driver that simulate flash that will compare running image version with what is present on card and then report to MCU boot that image is not there but this is just trickery to avoid unneeded writes.
Or we can add option to MCUboot to allow strict version comparison that will make flash driver much easier as it will not require to check other flash area.

So I'm not asking to alter existing behavior but to add option for strict compare if user wants it.

[Laczen]

@kasjer, I agree that in your use case it would be better to do a strict comparison.

The proposal you make to check the image version when "opening/mounting" the card slot seems to be the correct solution for this: when a upload over serial/usb is done it is allowed to reuse the version, when a upload comes from the sd-card it will only be presented when it has a higher version. I don't know if mcuboot allows any hooks to be called when opening slots but this would be ideal to support your scenario.