west: runners: Add ncs-provision to west flash command

[gchwier]

Added automatic KMU key provisioning for both NSIB and MCUboot. A new --ncs-provision command line option is added to nrfutil runner. This enables automated key provisioning during the flashing process to enable testing nRF54L applications using Twister.
Only applicable on NCS, when KMU keys are configured.

[fabiobaltieri]

should probably mention that these are not part of the tree and only found in nrf-sdk

[fabiobaltieri]

would it be better to mention that this requires "nRF Connect SDK" instead of a specific repository name? I think as it is it's not super clear what "sdk-nrf" is, if you mention your brand name for the SDK flavor it may be more obvious.

Also how does this fails if the command is run on a plain zephyr checkout? Would be nice to have a clear message there as well.

[gchwier]

Thanks for comment!
To enable it, you must explicite call --ncs-provision with west flash command. Also it is implemented only in nrfutil.py and must be enabled Kconfigs (SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU or SB_CONFIG_SECURE_BOOT_SIGNATURE_TYPE_ED25519) that are added in sdk-nrf. So there is no option to run it on a plain zephyr.

[fabiobaltieri]

ok so if one calls --ncs-provision it skips both _ncs_provision_for_nsib and _ncs_provision_for_mcuboot and fails silently right? would it make sense to print an error instead?

[gchwier]

If KMU keys are not enabled by Kconfigs (only available now on nrf54L family), then it just silently skips (not fails), so error is not needed, error is printed only when provisioning command fails.
And that command is only available with nrfutil runner, when using other runner then probable will receive argument error.

[fabiobaltieri]

Ok, are you sure that's the behavior you want? I could understand if it was an automatic feature (like file signing) but if you are asking the user to specify a flag explicitly to enable it, it sounds wrong to silently ignore it, I think it would make more sense to explicitly error out and say that the flag requires an NCS setup.

[gchwier]

Good point .. and I do not really know, what is best solution.
I've added that to enable testing with Twister, where you run thousands of tests on different platforms ... so when I call twister --west-flash="--erase,--ncs-provision" I do not want to see thousands of error messages (only couple of tests require provisioning).
And also worth to be noted, that:

• adding --ncs-provision to west flash will provision only one key used during building, this option will be rather useful for testing apps with Twister, or for developers / testers who don't want to run extra manual steps to up the board to check features not related with KMU
• the official instruction for customers is to flash the board (with nrfutil), run from nRF Connect SDK special command to provision keys (more keys can be provisioned for future use, can be enabled other features etc.) then reset

[fabiobaltieri]

Ok so if this errors out then you could not use it with twister right? guess there's no way to override this per test.

I see what you are doing but it's a bit of a poor user interaction to silently ignore the flag if it can't be used, no matter the reasons for it. @carlescufi @bjarki-andreasen what do you think?

[carlescufi]

If we choose to have this in Zephyr then I think the flag should check if the corresponding dependencies exist (e.g. the west extension command it is using) and fail otherwise.

[nashif]

Why are we adding all this NCS stuff into Zephyr? We need to figure out a better way where Zephyr remains clean of code needed only by a downstream and supported completely there.

[gchwier]

Why are we adding all this NCS stuff into Zephyr? We need to figure out a better way where Zephyr remains clean of code needed only by a downstream and supported completely there.

I agree with you about keeping downstream-specific code in the downstream repository, but I don't see an easy way to accomplish this (maybe to implement something like hooks that could be registered in the downstream project?)

I initially implemented this as a proof of concept in the downstream repository, but this created maintenance challenges when dealing with differences between repositories.

The primary motivation for including the NCS provisioning feature was to enable testing with Twister.
Currently, we can use pytest-harness with a multi-step process (flash with --no-reset, run provisioning, then reset the board).
There is no easy way to run tests without pytest-harness (one option might be adding post-flash scripts to the hardware map, but this also has limitations).

It's worth noting that this functionality is:

• Limited only to the nrfutil runner
• Contained within the nRF-specific runners files
• Activated only when explicitly requested with the --ncs-provision flag and when the proper Kconfigs are enabled

[carlescufi]

@nashif

Why are we adding all this NCS stuff into Zephyr? We need to figure out a better way where Zephyr remains clean of code needed only by a downstream and supported completely there.

Agreed, and this is already the case for almost all code in Zephyr, by extending the codebase in NCS itself.
As I see it, this one is slightly trickier than usual, because it needs to "inject" itself into the chain of operations that happens
during west flash, and the current runner infrastructure is not really extensible at all.

As @gchwier described, there are three real options in this particular case, due to the requirements of influencing the sequence of operations during flashing:

1. Keep this in Zephyr. It is quite well contained as @gchwier described, but this is functionality that is not useful in Zephyr upstream, not in NCS
2. Keep this whole patch in a Zephyr fork. Definitely doable, but quite ugly from a maintenance point of view
3. Some sort of hook that is specific to this particular runner, but that is tricky because it needs to extend the command-line parameters, not just execute at a point in time. Possible, but not trivial since the extra code is using the runner's internal APIs

[bjarki-andreasen]

Looking at the PR, why is generating a keyfile put into the twister runner? writing a keyfile to a target, sure, generating it? Seems this should be handled by a downstream script invoked by CMake, and passed to the runner like any other binary files.

Case in point:

Activated only when explicitly requested with the --ncs-provision flag and when the proper Kconfigs are enabled

so, we already use Kconfigs here, just pass those to CMake instead?

[gchwier]

Seems this should be handled by a downstream script invoked by CMake, and passed to the runner like any other binary files.

I must look into cmake scripts in sdk-nrf. I see that provisioning could be solved with:

• adding Kconfig (e.g. SB_CONFIG_PROVISION_DEFAULT_KEYS) in downstream
• generating keyfile during building (only downstream)
• in Upstream - extended NrfBinaryRunner->program_hex method with self.exec_op('x-provision-keys', keyfile=str(ncs_keyfile)), when Kconfig is enabled

I will try it, thank you!

[bjarki-andreasen]

Seems this should be handled by a downstream script invoked by CMake, and passed to the runner like any other binary files.

I must look into cmake scripts in sdk-nrf. I see that provisioning could be solved with:

• adding Kconfig (e.g. SB_CONFIG_PROVISION_DEFAULT_KEYS) in downstream
• generating keyfile during building (only downstream)
• in Upstream - extended NrfBinaryRunner->program_hex method with self.exec_op('x-provision-keys', keyfile=str(ncs_keyfile)), when Kconfig is enabled

I will try it, thank you!

Check out https://github.com/zephyrproject-rtos/zephyr/tree/main/soc/nordic/nrf54h/bicr where we do something like this :)

[carlescufi]

Thanks @bjarki-andreasen! If the file generation can be kept out of vanilla Zephyr then it’d be just about adding a new —provision parameter that would be compatible with both vanilla and NCS.

[gchwier]

Thanks @bjarki-andreasen! If the file generation can be kept out of vanilla Zephyr then it’d be just about adding a new —provision parameter that would be compatible with both vanilla and NCS.

I was rather thinking to not add any new parameter. Just check the build directory and if key file exists then run key provisioning.
This is added only for nrfutil runner and does not create any dependency to KConfigs. One can provision keys for NSIB, MCUboot or later for App (TF-m?).
In sdk-nrf we can add automatic keyfile generation in build process, if proper KConfig is set.
For now we can just create key file after building, before flash with west ncs-provision --dry-run command (key file is created only once, then is used every time after flashing).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud