MCUBoot build numbers in ncs

RE: MCUBoot build numbers in ncs

Einar Thorsrud — Tue, 05 Sep 2023 08:20:32 GMT

Hi,

Public cases are not closed per se, but you can mark it as answered. Pleas see this post for details.

RE: MCUBoot build numbers in ncs

KjellArne Amina — Tue, 05 Sep 2023 07:49:29 GMT

I'd like to close this issue, but cannot seem to find any close button in the web interface. Would you mind closing it for me?

RE: MCUBoot build numbers in ncs

Einar Thorsrud — Thu, 17 Aug 2023 11:31:07 GMT

Hi,

This is only tracked in our internal issue tracking system which is not externally available.

Br,

Einar

RE: MCUBoot build numbers in ncs

KjellArne Amina — Mon, 14 Aug 2023 10:56:58 GMT

Great, then it all makes sense. I'll take efforts to be more clear the next time i post.

Thanks for the suggestion, I did some more changes to actually include the build number in the header, but the following struct packing puts the build number at the wrong position in the OTA image header. I'll attach my code for reference, even though it is certainly not the best way to do it.

Is there a link to an issue tracking that can be shared, or is it only used internally at Nordic?

devzone.nordicsemi.com/.../zb_5F00_add_5F00_ota_5F00_header.py

RE: MCUBoot build numbers in ncs

Edvin — Fri, 11 Aug 2023 12:01:27 GMT

Ah! By "does not take build number into account" I thought you meant that it just ignored the build number, not that it didn't build.

Try this:

def convert_version_string_to_int(s):
    """Convert from semver string "1.2.3", to integer 1020003"""
    head, sep, tail = s.partition('+')
    numbers = head.split('.')
    if len(numbers) != 3:
        raise ValueError('application-version-string parameter must be on the format x.y.z')
    js = [0x100*0x10000, 0x10000, 1]
    return sum([js[i] * int(numbers[i]) for i in range(3)])

I will report it to our SDK team, so hopefully it will be fixed in a future release.

I don't know if this is the best way to do it in python, but it looks like it is working, at least.

Best regards,

Edvin

RE: MCUBoot build numbers in ncs

KjellArne Amina — Fri, 11 Aug 2023 07:01:37 GMT

I mean that downgrade prevention and semantic versioning is nice and all, but what we want to use and need help with is that the build fails when we use build number.

As for the problem we're having, please refer to my original post:

[quote userid="126530" url="~/f/nordic-q-a/102654/mcuboot-build-numbers-in-ncs"]The nRF Connect SDK seems to handle this in "convert_version_string_to_int()" in "zb_add_ota_header.py", but this function does not take build number into account. Could you please patch this, and preferably share the code if the release of the fix takes a long time?[/quote]

The error message we see when trying to use build number looks something like this:

FAILED: modules/mcuboot/CMakeFiles/zigbee_ota_image
cd /home/username/code/product/build/modules/mcuboot && /home/username/util/ncs/toolchains/1f9b40e71a/usr/local/bin/python3.8 /home/username/util/ncs/v2.4.1/nrf/scripts/bootloader/zb_add_ota_header.py --application /home/username/code/product/build/zephyr/dfu_multi_image.bin --application-version-string 0.3.2+10 --zigbee-manufacturer-id 0xDEAD --zigbee-image-type 0xCAFE --zigbee-comment company_OTA_image --zigbee-ota-min-hw-version --zigbee-ota-max-hw-version --out-directory /home/username/code/product/build/zephyr
invalid literal for int() with base 10: '2+10'

RE: MCUBoot build numbers in ncs

Edvin — Fri, 11 Aug 2023 06:20:27 GMT

[quote user="KjellArne"]We aren't concerned about downgrade prevention when we want to use build number, but rather traceability of the.[/quote][quote user="KjellArne"]What is the intended way to use build number, if not for traceability?[/quote]

I am not sure what you mean. If you are not concerned with downgrade protection, then what is the issue with the build number? Are you struggling to set it? Are you struggling to read it?

BR,
Edvin

RE: MCUBoot build numbers in ncs

KjellArne Amina — Thu, 10 Aug 2023 13:41:19 GMT

We aren't concerned about downgrade prevention when we want to use build number, but rather traceability of the. We could of course add the build number to the filename, but that is too easily changed.

What is the intended way to use build number, if not for traceability?

RE: MCUBoot build numbers in ncs

Edvin — Thu, 10 Aug 2023 12:25:30 GMT

[quote user="KjellArne"]My bad, it did not work with west build, zb_add_ota_header.py is used there as well[/quote]

That makes sense, since VS Code is just a GUI wrapped around west.

You can do that, but as it states, it is a downgrade protection, which means that you can't DFU back to a lower version, but you can DFU within the same version. Therefore it makes sense to only publically release one image per revision, I guess.

BR,
Edvin

RE: MCUBoot build numbers in ncs

KjellArne Amina — Thu, 10 Aug 2023 10:45:49 GMT

My bad, it did not work with west build, zb_add_ota_header.py is used there as well.

The plan was to use the following way, again from your docs in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/bootloaders_and_dfu/fw_update.html#software-based-downgrade-prevention

west build -b board application -- \
-DCONFIG_MCUBOOT_IMAGE_VERSION=\"0.1.2\+3\"

RE: MCUBoot build numbers in ncs

Edvin — Thu, 10 Aug 2023 06:42:15 GMT

[quote user="KjellArne"]It works using west build, but does not work in the VS Code NCS plugin.[/quote]

What do you mean by this? Are you able to include the build number in the version check using west build, but not in VS Code? If so, how do you do that?

Best regards,

Edvin

RE: MCUBoot build numbers in ncs

KjellArne Amina — Wed, 09 Aug 2023 13:13:35 GMT

Thanks for your reply. Great, then I understood correctly how major, minor, revision and build number works, but it was courteous of you to ensure we are both on the same page.

We simply read your documentation and wanted to use the build number as described, see for instance the MCUBoot image format documentation: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/design.html#image-format

It works using west build, but does not work in the VS Code NCS plugin. I assumed this was a simple oversight on Nordic's end, but should probably have been more clear in my original question.

RE: MCUBoot build numbers in ncs

Edvin — Wed, 09 Aug 2023 09:30:38 GMT

I see. Basically, everything after + will be ignored.

This means that if I build two different applications, both with image version "1.2.3", then I will be able to do DFU between these, back and forth.

However, I will not be able to DFU to an image version lower than the one that it is already on, e.g. "1.2.2". This is to prevent possible bugs and loopholes in earlier versions of the firmware. Therefore it is important that if you fix bugs and possible security holes, you need to increase the image version, so that it is no longer possible to DFU to the version that contains the security risk.

For your request to make sense, you would have to implement something that doesn't accept the same image version, but requires a strict increase. Without this feature, it doesn't really make sense to separate on the build numbers.

That being said, I don't really see the need for taking the build number into account (and personally I have never used it). From a security perspective, it doesn't really make any difference. For you as a company, as long as you keep your keys secret, you only need to make sure to increase the version number by at least one every time you roll out an update. You will still have a lot (!) of update numbers, so you probably won't run out during the lifetime of the product.

Best regards,

Edvin

RE: MCUBoot build numbers in ncs

KjellArne Amina — Tue, 08 Aug 2023 12:52:33 GMT

Yes, that is correct. The note in "Software based downgrade prevention" (see previous link) calls the "+3" a "label or build number"

The optional label or build number specified after the + character is ignored when evaluating the version. An existing application image with version 0.1.2+3 can be overwritten by an uploaded image with 0.1.2+2, but not by one with 0.1.1+2.

It is not stored anywhere as such, but we provide it our prj.conf file as a config parameter:

CONFIG_MCUBOOT_IMAGE_VERSION="1.2.3"

RE: MCUBoot build numbers in ncs

Edvin — Tue, 08 Aug 2023 12:18:50 GMT

Hello,

What do you mean by build number, and where is it stored? Do you refer to the "+3" in the section you linked to?

Best regards,

Edvin