hw_unique_key sample can not run in NS mode

[Tide]

Hi ,

When i run  samples/keys/hw_unique_key  app and select  nrf9160dk_nrf9160_ns board . The app can not run into  main function  instead run into system_halt.

__WEAK void tfm_hal_system_halt(void)

{

    /*

     * Disable IRQs to stop all threads, not just the thread that

     * halted the system.

     */

    __disable_irq();

    /*

     * Enter sleep to reduce power consumption and do it in a loop in

     * case a signal wakes up the CPU.

     */

    while (1) {

        __WFE();

    }

}

 

At the same time I tested some other samples with 'CONFIG_TFM_PROFILE_TYPE_NOT_SET=y' configured, none of them work properly in non-secure mode.

Why is this happening please help.

[Einar Thorsrud]

Hi,

I am not able to reproduce this on my end (using nRF Connect SDK 2.1.1). Which nRF Connect SDK version are you using?

[Tide]

The sdk version I am using is also 2.1.0

[Einar Thorsrud]

I see, then it should work. Can you check if you have done any accidental changes in the SDK code, or for instance check it out again? Are you using the toolchain manager to install it, if not can you try that?

If that does not help, can you share the details about how you are building and testing, step by step so that I can attempt to reproduce exactly what you are doing?

[Tide]

Yes, I can run it normally in no-secure application. However, when I run hw_unique_key in a secure application(Wrapper functions in tfm_ioctl_ns_api.c and tfm_ioctl_s_api.c), it still jumps to the system_halt function.
Are there any examples how to use Huk and crypto in a secure application?

[Einar Thorsrud]

Hi,

Tide said:

However, when I run hw_unique_key in a secure application(Wrapper functions in tfm_ioctl_ns_api.c and tfm_ioctl_s_api.c), it still jumps to the system_halt function.

That is odd. This sample works with both secure and non-secure out of the box for me, and both nrf5340dk_nrf5350_cpuapp and nrf5340dk_nrf5350_cpuapp_ns are officially supported targets.

Can you double check that you have nod made any changes to the SDK source, and demonstrate how this fails on your end? Perhaps you can provide step-by-step instructions on how to make this fail?

Tide said:

Are there any examples how to use Huk and crypto in a secure application?

That is the hw_unique_keys sample, which demonstrates this for both secure and non-secure.

[Tide]

Yes, hw_unique_key in sdk select nrf9160dk_nrf9160 and nrf9160dk_nrf9160_ns boards both work fine on my end. 
Selecting the nrf9160dk_nrf9160_ns board will set
CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y

Selecting the nrf9160dk_nrf9160 board will set
CONFIG_MBEDTLS_PSA_CRYPTO_C=y
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_HW_UNIQUE_KEY=y
CONFIG_HW_UNIQUE_KEY_RANDOM=y

But we need to do it, our application runs in a non-secure program, hw_unique_key and crypto(ecdsa) in a secure program. In no-secure, the application calls hw_unique_key and crypto through the TF-M IOCTL interface.

I have tried both configurations of nrf9160dk_nrf9160 and nrf9160dk_nrf9160_ns above, hw_unique_key is not working properly in secure application.

[Einar Thorsrud]

Hi,

Just to be clear, did the unmodified hw_uneque_key run well in both secure and non-secure on your end? It should, and does for me.

Is the problem that you have problems with your custom application? If so, can you provide a minimal failing project or explain in more detail how I can reproduce this on my end? Or clarify in detail what you do and what you see when debugging (including logs etc) so that we can get some idea about what could be the problem in your application?

[Tide]

Just to be clear, did the unmodified hw_uneque_key run well in both secure and non-secure on your end? It should, and does for me.

yes,  the unmodified hw_uneque_key run well in both secure and non-secure on my end.I'll share my custom code with you.

[Tide]

Hi,

Can you provide an email address? I will send you the custom code.

[Einar Thorsrud]

Hi,

Please open a private support case and upload the code there and refer to this thread. That way the code is handled in confidentiality and only accessible for the Nordic technical support team.