• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 12 replies
  • Subscribers 76 subscribers
  • Views 4302 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 249383
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Updatable bootloader for nrf9160

gregers

Hi, I'm confused how to do fota of mcuboot on the nrf9160.

The source code is public on github in this branch: https://github.com/ExploratoryEngineering/nrf9160-telenor/tree/immutable-bootloader

fota sample is here: https://github.com/ExploratoryEngineering/nrf9160-telenor/tree/immutable-bootloader/samples/fota

The sample use lwm2m to download a new firmware image from our (Telenor's) IoT gateway. It's just standard LwM2M, and uses dfu_target to flash the new firmware. I have enabled CONFIG_SECURE_BOOT to use the immutable bootloader and use CONFIG_FW_INFO_FIRMWARE_VERSION to bump mcuboot's version.

I've tried to read the source code to understand what's going on, but I'm struggling to understand a few pieces. According to the mcuboot design docs, I get the impression that image swaps only happen between the image slots. However the dfu_target doesn't look at the image header before flashing the image to the secondary slot for the application instead of s1. I might be missing some magic configuration or call to change this behaviour, but I can't find it. By commenting out the reboot I can verify that the image is actually written to the secondary slot:

$ nrfjprog -f nrf91 --memrd 0x94400 --n 28
0x00094400: 281EE6DE 8FCEBB4C 00005B02 0000003C   |...(L....[..<...|
0x00094410: 00009080 00000002 00015200            |.........R..|

The secondary slot starts at 0x94000 and by looking at the fw_info data we can see that this is version 2 and the start of the image is 0x15200, which is where s1 is located.

Double check fw_info for s0 and s1:

$ nrfjprog -f nrf91 --memrd 0x8400 --n 28
0x00008400: 281EE6DE 8FCEBB4C 00005B02 0000003C   |...(L....[..<...|
0x00008410: 00009080 00000001 00008200            |............|

$ nrfjprog -f nrf91 --memrd 0x15400 --n 28
0x00015400: 281EE6DE 8FCEBB4C 00005B02 0000003C   |...(L....[..<...|
0x00015410: 00009080 00000001 00015200            |.........R..|

When calling dfu_target_done, it writes BOOT_SWAP_TYPE_TEST to the FLASH_AREA_IMAGE_SECONDARY swap field.

On the next reboot the immutable bootloader choose s0, since s1 is not changed in flash yet. Then (old) mcuboot does it's magic and boots the application. Now if I look at the flash, s1 has been updated with the image flashed to the secondary slot:

$ nrfjprog -f nrf91 --memrd 0x8400 --n 28
0x00008400: 281EE6DE 8FCEBB4C 00005B02 0000003C   |...(L....[..<...|
0x00008410: 00009080 00000001 00008200            |............|

$ nrfjprog -f nrf91 --memrd 0x15400 --n 28
0x00015400: 281EE6DE 8FCEBB4C 00005B02 0000003C   |...(L....[..<...|
0x00015410: 00009080 00000002 00015200            |.........R..|

In the fota code in our application we would like to see what version and slot the bootloader is using. We used fw_info to check this, but even though s0 was used during boot fw_info will report what's on flash after booting, so it will look like s1 was used since it's valid and has a higher version.

By manually rebooting, the immutable bootloader now sees version 2 in s1 and boots from 0x15200. However I don't know how we'll be able to detect this state from code and trigger the second reboot.

Sorry for the long explanation. Here are my questions:

  • Are we doing something wrong since the dfu_target stores the image in the wrong slot? (or is it not wrong)
  • mcuboot only has one public key embedded to verify the signature of the application. If we want to change this key, I assume we have to update both mcuboot and the application in flash before rebooting. How can we do this if both are stored in the secondary slot?
  • Is it possible to do a test run of mcuboot before persisting it?
  • The immutable bootloader have a list of public keys stored in the OTP area for verifying the mcuboot signature. Will we brick the device if we upload a new version of mcuboot signed with a new key and mcuboot or the application fails the test? Looks like all previous public keys are invalidated before the new images are marked OK. Is this intentional?
  • I've read that images can have dependencies between them, so when one fails mcuboot will roll back the others. Is this used automatically for mcuboot and the application, or does it not make sense to use for the bootloader?
  • I have a few suggestions for improving the documentation. What is your preferred method of giving feedback on the documentation? Do you have a public github for the docs hosted on https://developer.nordicsemi.com?
Parents
  • 0

    Thank you for the thorough answer shibshab!

    shibshab said:
    We made a modification to MCUBoot where two images can _share_ the secondary slot.

    I don't understand why this choice was made rather than storing the image in the slot for the corresponding image in the first place. I would rather have that fixed than filing an issue upstream. Is this a temporary solution, or do you have a plan to fix this?

    shibshab said:
    I see your point, this would be fixed if mcuboot did a reset after performing the update of mcuboot, do you agree?

    It's a hack that could work to update mcuboot (without changing app signing key) until the issue above is solved.

    shibshab said:
    Again, because of the single secondary slot this is not supported.

    It would be really nice if the images were flashed to the corresponding slot, so we could update both at once and be able to roll back when one of them fails. Also without invalidating the old public key.

  • 0 in reply to gregers

    Our assumptions is that the bootloader will be changed 100 times less than then application. The reasons would be 1 - security flaw discovered, or 2 - its no longer able to update the application properly (several reasons why this might happen). Hence we did not see a big loss of functionality when removing the support for simultaneous update of mcuboot and application. The cost, however, of supporting simultaneous update is severe for most applications in terms of flash space used. 

    IMO it would be a small change to get the behavior you describe, just remove the NCS patch in loader.c (diff the ncs fork from the upstream) which enables sharing of the secondary slot, and modify dfu_target to check the vector table (like we do in the ncs version of loader.c) when choosing which secondary slot to store the image to.

  • 0 in reply to shibshab
    shibshab said:
    The reasons would be 1 - security flaw discovered, or 2 - its no longer able to update the application properly (several reasons why this might happen).

    You would also need to update the bootloader if the signing key gets leaked. Of course you should secure the private key properly. But with the lack of best practices on the subject, I'd say it's quite likely some of your customers will experience this.

    shibshab said:
    Hence we did not see a big loss of functionality when removing the support for simultaneous update of mcuboot and application.

    Except that it's impossible to change the application signing key without disabling the signature check while updating.

    shibshab said:
    The cost, however, of supporting simultaneous update is severe for most applications in terms of flash space used.

    I don't understand why. The vector table is in the beginning of the image, so it should be possible to detect the correct address very early in the download process. Right? I don't have much experience with this, so I haven't really thought this through, but would like to understand. Is the unused bootloader slot write protected, or can the application write to the slot that is not in use?

    Thank you for the tip about loader.c. I got the diff, and will test it out.

Reply
  • 0 in reply to shibshab
    shibshab said:
    The reasons would be 1 - security flaw discovered, or 2 - its no longer able to update the application properly (several reasons why this might happen).

    You would also need to update the bootloader if the signing key gets leaked. Of course you should secure the private key properly. But with the lack of best practices on the subject, I'd say it's quite likely some of your customers will experience this.

    shibshab said:
    Hence we did not see a big loss of functionality when removing the support for simultaneous update of mcuboot and application.

    Except that it's impossible to change the application signing key without disabling the signature check while updating.

    shibshab said:
    The cost, however, of supporting simultaneous update is severe for most applications in terms of flash space used.

    I don't understand why. The vector table is in the beginning of the image, so it should be possible to detect the correct address very early in the download process. Right? I don't have much experience with this, so I haven't really thought this through, but would like to understand. Is the unused bootloader slot write protected, or can the application write to the slot that is not in use?

    Thank you for the tip about loader.c. I got the diff, and will test it out.

Children
  • +1 in reply to gregers

    So if you loose your signing key, you can (as I might have mentioned above) update mcuboot with a new version which has a new key, but does not perform validation on boot-up, only on DFU. This way you should be able to only accept new updates signed with the new key.

    Yes, the unused bootloader slot is write protected. There are several reasons for this, the most important one being hardware limitations on how small blocks of flash can be write protected. Since the minimum size is 32kB we squeeze 2 mcubootinstances inside (s0 and S1) and use 32kB for mcuboot instead of 64kB.

  • 0 in reply to shibshab

    I've attempted disabling boot validation by adding CONFIG_BOOT_VALIDATE_SLOT0=n to the mcuboot config and re-compile mcuboot and application with a new signature file for the application. However mcuboot refuse to swap the new mcuboot image into s1 with the error: «Image in the secondary slot is not valid!». This is strange, since I have only changed the signature file that is used for signing the application. So mcuboot should be signed with the same key. Not entirely sure I'm doing this correctly though, since I had to specify the signature file with CONFIG_BOOT_SIGNATURE_KEY_FILE for both the application and mcuboot. I had to do that to get mcuboot to validate the application with the key that was used in the application and not the default key in mcuboot - since the cmake code strips all previous CONFIG_* when adding a new target.

    Did I configure it incorrectly? Please see the github repo for how I've specified signature files in the config.

    I also looked into the flash access control that you mentioned. Assuming the 32 regions of 32 kB start at address 0 and increase by 0x8000 for each region, the mcuboot s0 starts at 0x8000 - which makes sense. However it's not correct that both mcuboot slots fit into one of these regions. The size of one slot it 0xC200, or roughly 50 kB. So you could almost squeeze both slots into three regions, but s1 starts at 0x15000 and goes 4608 bytes into the 5th region that starts at 0x20000. So in practice they use 4 of the 32 kB regions.

    Looking at the mcuboot fork, it seems like the flash protection was added after the last release (sdk 1.2), and can be disabled from config. The patch to loader.c is part of sdk 1.2, so the reason for patching loader.c to write the mcuboot image to the applications secondary slot couldn't have been because s0 and s1 was write protected. Could it be another reason why you decided to patch loader.c?

    To me it seems strange to disable the «chain of trust» to be able to flash protect the mcuboot slots. If you reverted the patch to loader.c (or at least have it configurable) so the image would be written to the slot it belongs, we could rely on «chain of trust» during boot instead - and updating both mcuboot and the application simultaneously would be possible.

  • 0 in reply to gregers

    You should sign the mcuboot update with the OLD key, but it should contain the NEW key inside itself, was this what you did? To do this I think you have to manually invoke the imgtool.py scripts. See the build.ninja file in your build directory for examples of signing commands.

    The sizes in the default configurations are not 16kB each, you are correct. To achieve this you need to optimize the mcuboot image, and re-use the crypto from B0 instead of having mcuboot using its own.

    There is an open PR fixing the order in main.c of our fork, since mcuboot updates were practically broken since the flash was locked before any swaps happened.
    https://github.com/NordicPlayground/fw-nrfconnect-mcuboot/pull/97

    When working correctly the chain of trust is not broken.
    What is important is to protect mcuboot from tampering by the application, once this is in place you can more safely disably on-boot verification.

    I agree that a scheme of updating both mcuboot and application simultaneously would be beneficial (especially since external flash would be in place for most 91 devices AFAIK), but this is not something we have planned for now.

  • 0 in reply to shibshab
    shibshab said:
    You should sign the mcuboot update with the OLD key, but it should contain the NEW key inside itself, was this what you did?

    That's what I tried. We use a different key for mcuboot and the application, and I've only changed CONFIG_BOOT_SIGNATURE_KEY_FILE when testing. mcuboot is signed using CONFIG_SB_SIGNING_KEY_FILE, which hasn't been modified. So mcuboot should be signed using the same key as before, whereas the public key for the application should be in the fresh build of mcuboot.

    shibshab said:
    To do this I think you have to manually invoke the imgtool.py scripts. See the build.ninja file in your build directory for examples of signing commands.

    Really? Isn't it the immutable bootloaders responsibility to validate the signature of mcuboot using the public keys stored in the OTP area? As far as I can tell from studying the cmake files, the provision hex generated for the OTP area extracts the public key from SB_SIGNING_KEY_FILE and includes SB_PUBLIC_KEY_FILES. As far as I can tell, mcuboot is signed using SB_SIGNING_KEY_FILE. But I don't understand how mcuboot is supposed to validate the signature of mcuboot in the dfu process when it doesn't have the public key.

    I thought CONFIG_SB_SIGNING_KEY_FILE was the file used to sign mcuboot when using the immutable bootloader. Haven't changed that file, only CONFIG_BOOT_SIGNATURE_KEY_FILE.

    shibshab said:
    The sizes in the default configurations are not 16kB each, you are correct. To achieve this you need to optimize the mcuboot image, and re-use the crypto from B0 instead of having mcuboot using its own.

    Is this just a matter of config options? Would be nice with a sample demonstrating more of this. Documentation is really scarce when trying to do this properly.

    shibshab said:
    There is an open PR fixing the order in main.c of our fork, since mcuboot updates were practically broken since the flash was locked before any swaps happened.

    Sorry for being difficult, but you're avoiding answering my question. I don't see why I need protecting the mcuboot flash area when the immutable bootloader is validating the signature. What I'm curious about is why you decided to patch mcuboot, so the update candidate is written to the secondary slot instead of the address it belongs.

    The reason for asking is that I would like to know if it's worth it for us to revert the patch and implement multi image dfu ourselves. If there are other problems than the flash protection, we'd like to know before starting on this Slight smile

Related
Terms of service