Encrypted FW update with MCUboot fails.

Hello,

I'm having trouble making encrypted FW update with MCUboot work in NCS 2.5.0. There are no issues with update of signed but not encrypted FW. But when encrypted FW is uploaded, it gets rejected. It turned out that after uploading encrypted FW file to secondary slot, MCUboot verifies it by checking if reset address of new FW is within address range of primary slot (where the new FW needs to be copied to). Code from boot_validated_swap_type() function in \ncs\v2.5.0\bootloader\mcuboot\boot\bootutil\src\loader.c :

        rc = flash_area_read(secondary_fa, hdr->ih_hdr_size +
                             sizeof(uint32_t), &reset_addr,
                             sizeof(reset_addr));

...

            /* Check start and end of primary slot for current image */
            if (reset_addr < primary_fa->fa_off) {

...

                return BOOT_SWAP_TYPE_NONE;

...

            } else if (reset_addr > (primary_fa->fa_off + primary_fa->fa_size)) {

...

                return BOOT_SWAP_TYPE_NONE;
            }

Reset address off new FW is taken from payload part of update file. This part of file is encrypted. No decryption is done at this step. So it depends only on luck if encrypted address falls within rages of primary slot. In my case it does not. If I fake reset address before this check is done, everything works fine: new FW is successfully decrypted and copied to primary slot.

if (primary_fa->fa_off == 0x31000) reset_addr = primary_fa->fa_off;

Is this a bug in MCUboot part of NCS or am I missing something? Do you have any suggestions how to overcome this issue without modifying code of SDK?

Parents Reply
  • That explains it. The reset vector check is an addition in our MCUBoot fork to help determine where the update image belongs:

    /* Patch needed for NCS. Since image 0 (the app) and image 1 (the other
    * B1 slot S0 or S1) share the same secondary slot, we need to check
    * whether the update candidate in the secondary slot is intended for
    * image 0 or image 1 primary by looking at the address of the reset
    * vector. Note that there are good reasons for not using img_num from
    * the swap info.
    */
    The problem is that this patch does not take encryption into account. This would have worked if you had not included the b0 bootloader with the additional s0 and s1 slots.
Children
Related