MCUBOOT behavior on primary image validation fail

[Shikamaru]

Hi team,

             I have some doubts regarding mcuboot behavior on firmware failure.

1) Consider the situation I have flashed a new  image , it will get validate before mcuboot using this. So at earlier stage consider it got validated and mcuboot booted the image successfully. After 4-5 days or you can say month later that image got corrupted (i.e. running image) , what mcuboot will do at that time. 

note -  even though we do have 2 image in 2 slots , does mcuboot will go back to previous image.,?? 

-- at the time of booting if the  image is corrupted during bootup time , mcuboot will erase that image and go back to the previous image that is fine. but what about that image is corrupted after 5 days of running or after an month.

regards,

Shikamaru

[Simon]

I did some quick tests myself. I followed the DFU guide and performed a DFU update, such that there were an image in the primary slot and an image in the secondary slot. Then I corrupted the image in the primary slot by writing to it using nrfjprog --memwr... Then mcuboot gave the following log after resetting the chip:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
E: Image in the primary slot is not valid!
E: Unable to find bootable image

So by default, mcuboot won't revert back to the image in secondary slot when the image in the primary slot is corrupted. I will ask internally if there is any way to change this behaviour.

Best regards,

Simon

[Shikamaru]

Thanks Simon ,

        

Simon said:

So by default, mcuboot won't revert back to the image in secondary slot when the image in the primary slot is corrupted

Okays,Noted ....Is there any mechanism to overcome this issue,

Simon said:

I will ask internally if there is any way to change this behaviour.

yep that will be helpful. 

regards,

Shikamaru

[Simon]

It is not possible to make mcuboot revert to using the image in secondary slot if the validation of the image in primary slot fails, since it's not a secure operation. Then a bit flip could be triggered in the primary slot, causing an old "buggy" version to run.

Best regards,

Simon

[Shikamaru]

Simon said:

Then a bit flip could be triggered in the primary slot, causing an old "buggy" version to run.

I didn't get this point. Can you elaborate a bit.

[Simon]

Simon said:

Then a bit flip could be triggered in the primary slot, causing an old "buggy" version to run.

At startup, mcuboot will perform a hash validation of the primary image, and if a single bit is changed (bit flip), then the hash validation will fail and it will not boot the primary image.

Let me explain with a scenario where mcuboot allows image in secondary slot to run if image in primary slot is corrupted

1. You have a product 
2. Then you discover a bug in the firmware, it couold be a security bug that makes the firmware vulnerable for attacks.
   1. Primary slot: Firmware with bug
   2. Secondary slot: Empty
3. To fix the bug, you perform a DFU
4. Then the bug-free firmware will be put in the primary slot and the old firmware with the bug will be swapped into the secondary slot
   1. Primary slot: New firmware with no bugs
   2. Secondary slot: Firmware with bug
5. Then if a hacker manages to flip a bit in the primary image, mcuboot will swap the images and let the buggy firmware run. So you end up with the following:
   1. Primary slot: Firmware with bug
   2. Secondary slot: Firmware with no bugs

The state in point 5 is not a situation you would want to be in

Hopefully you understand it better now

If you want to be able to update the image in the primary slot, you could let mcuboot do the DFU instead of the application. Then you can update the primary slot if that image is corrupted.

Best regards,

simon