Best process for signing firmware images when using mcuboot

[d_c_h_w]

I am developing an applicaiton to run on the app core of an nRF5340, and I have mcuboot enabled for the purposes of handling DFU.

I have recently implemented signing the app firmware with our own pem key instead of using the default key provided by mcuboot.

I am raising this support request as there does not seem to be a set ideal way to accomplish this automatically. If have tried two methods, and since upgrading to v1.5.0 have changed to using Method B.

Method A)

Specify in cmakelists.txt that we are in charge of the config of mcuboot e.g. via 

set(mcuboot_CONF_FILE
${CMAKE_CURRENT_SOURCE_DIR}/boards/mcuboot.conf
)

Advantages	Disadvantages
Uses the immediate path of the conf file, so we can have the pem file inside our repository rather than the nRF Connect SDK source tree	Have to maintain the full conf info for mcuboot, which generally changes in configuration between SDK revisions. Several changes observed going from v1.4.2 to v1.5.0
	Goes against the idea of having the child_image directory to control small tweaks to the standard configuration of mcuboot that has been added in v1.5.0

Method B)

Use child_image mcuboot conf file to specifiy the pem file

Advantages	Disadvantages
Don't have to maintain a full conf file for mcuboot	Have to copy it into mcuboot area of SDK source code checkout. This is the only Path it looks in, and full paths are 1. a bit unworkable and 2. discouraged.
	Having it stored at this path seems to trigger the cmake warning regarding using standard mcuboot key and that it should not be used in production, which is confusing to say the least. See warning below

Am I missing something here, or are these the simplest options.

[Simon]

Would any of these methods work?

• "In a dedicated `mcuboot_prj.conf` and pass it to the build system as: `-Dmcuboot_CONF_FILE=mcuboot_prj.confI
  containing:
  CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem
  If using this method, CONFIG_BOOT_SIGNATURE_KEY_FILE <path> can be omitted and path will be taken relative to the location of the conf file.
• In a Kconfig fragment, like: mcuboot_overlay-keys.conf , and pass it to the build system as: `-Dmcuboot_OVERLAY_CONFIG=mcuboot_overlay-keys.conf` containing:
  Path must be absolute in this case.
  CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem
• using `-Dmcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE=<path>/public-key.pem`.
  Path must be absolute in this case."

Best regards,

Simon

[d_c_h_w]

Hi Simon, Thank you for your response and suggestions.

I think your first option is basically the same as my first option. The down side to this seems to be as it is the main conf file now for mcuboot it requires extra config options for it to be the same as a letting it configure itself.

The other two options rely on absolute paths which I am not keen on, as I work locally in Windows with SES, but have a docker environment under linux that creates builds too.

I think I will stick with my 2nd option for now, it's a shame that the cmake warning logic is a bit wrong assuming any key in the mcuboot directory must be a default one

[Simon]

Try doing this instead:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
    list(APPEND mcuboot_OVERLAY_CONFIG
      "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf"
      )
endif()

From https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.5.0/zephyr/application/index.html?highlight=overlay_config#important-build-system-variables: 

"OVERLAY_CONFIG: Additional Kconfig configuration fragment files. Multiple filenames can be separated with either spaces or semicolons. This can be useful in order to leave CONF_FILE at its default value, but “mix in” some additional configuration options."

[d_c_h_w]

Hi Simon,

I have just tried that, and this expects the pem file in the source mcuboot directory (or use a absolute path), so it is the same as creating an append overlay in the child_image directory.

In fact, I think the new v1.5.0 feature of the child_image directory is a neatened up implementation of doing what you have suggested.

I will stick with the new child_image method and just pre-copy across the pem file to the mcuboot directory, and ignore the cmake warning.

Thanks for all your suggestions

[lcoudeville]

I tried to walk on this approach, but unfortunately this doesn't work with the latest ncs (1.9.1). I digged deeper to reveal that something is loose with the "add_overlay*" functions/macro's. After investigating a lot of time I'm still not able to say what's wrong. I temporarily resolved this issue by using the "child_image" approach. But I want to share the issue, so it can be resolved in one of the upcoming ncs releases.

Setting the variable in the cmake file doesn't seems to work:

set(mcuboot_OVERLAY_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot_prj.conf")

For some reason, this late overlay config(s) are not appended when building the project. So the nrf/subsys/partition_manager/partition_manager_enabled.conf file is not loaded resulting in mcuboot errors.

The strange thing is supplying it over the command line works:

west build -p=always -- -Dmcuboot_OVERLAY_CONFIG=$(pwd)/mcuboot_prj.conf && west flash

Adding some debug info shows that "mcuboot_OVERLAY_CONFIG" only contains the path set in the CMakeLists.txt and not the appended files by the ncs scripts (in my case the partition_manager_enabled.conf file).