Zephyr ITS on settings/nvs, data does not persist through reset

[Anthony Ambuehl]

I'm working on an application using ITS.  Since I'm currently having difficulty getting non-minimal TFM to work on the nrf9160, I have temporarily switched to not use TF-M with the 9160.

I'm using NCS 2.3.0 with Zephyr ITS with Settings/NVS underneath.

Here are the conf settings:

ONFIG_PSA_NATIVE_ITS=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

(I can provide complete project build privately)

I am finding 2 issues:

1) The data saved in the first call to psa_its_set  is not the same when I read it back with psa_its_get.  All the operations succeed, but the data is changed.  I have bypassed the issue by always calling psa_its_get immediately after psa_its_set and if the data doesn't match I retry the operation. 

2) I'm finding after a reset that the data is no saved.  During the boot-up I see the following messages:

[00:00:00.258,544] <inf> fs_nvs: No GC Done marker found: restarting gc
[00:00:00.434,448] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.434,478] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:00.434,478] <inf> fs_nvs: data wra: 0, 0

Is there some sort of NVS initialization that is necessary to make the zephyr ITS on Settings/NVS work?

[Sigurd Hellesvik]

Anthony Ambuehl said:

are you saying TF-M is REQUIRED for nrf9160?  That seems strange.  I assume there are examples of using nrf9160 modem without TF-M. 

If I add CONFIG_NRF_MODEM_LIB and CONFIG_BOOTLOADER_MCUBOOT (for partition manager) to the hello world example and build for nrf9160dk_nrf9160, I get the following error:

home/sihe/ncs/nrf/lib/nrf_modem_lib/nrf_modem_lib.c:20:2: error: #error nrf_modem_lib must be run as non-secure firmware. Are you building for the correct board ?

This is from https://github.com/nrfconnect/sdk-nrf/blob/main/lib/nrf_modem_lib/nrf_modem_lib.c#L20-L21

Also documented in Modem lib docs:

"

To use the Modem library, you must make sure that the following requirements are met:

• The application using the Modem library is run in Non-Secure Processing Environment (NSPE).

• The IPC and FPU peripherals are available in NSPE.

• The shared memory resides in the lower 128 KB of RAM.

• The application provides an implementation of the OS interface in the nrf_modem_os.h file.

• The library depends on the nrfx IPC driver or equivalent IPC driver.

"

So you need non-secure firmware (which is done either by the old SPM or the new TF-M) to use our Modem Lib, which is our default and recommended method for using the modem.

Anthony Ambuehl said:

Also BTW, Zephyr does include an implementation of ITS separate from TF-M, however it seems to be incomplete/buggy.

From what I know about ITS, it leverages the Isolation from TF-M from storage.
So other that easy changing between TF-M and non-TF-M builds, I do not see the advantage of this feature.
That being said, Zephyr developers probably know more than me, so might be some good reasons here that I do not see yet.

[Anthony Ambuehl]

My only intention with using PSA Crypto with Zephyr ITS was to have a consistent API and not need to test and maintain 2 different versions of the code.  

With the requirement to have a NSPE for the modem library, I suppose I will need to resume my effort to fit NSIB/Mcuboot/TF-M (experimental) into the nrf9160, that is ultimately the preferred environment for this effort anyway.

[Sigurd Hellesvik]

Anthony Ambuehl said:

My only intention with using PSA Crypto with Zephyr ITS was to have a consistent API and not need to test and maintain 2 different versions of the code.  

The PSA Crypto API is as you say available for both with and without TF-M.
The PSA Crypto API will use ITS as a storage backend if it is available (TF-M active)
If TF-M is not enabled, the PSA Crypto API will not use ITS for key storage, and instead other methods.

So while you can not use ITS as such a consistent API, I think you should be able to use the PSA Crypto API as such.

[Anthony Ambuehl]

We have additional data that we need to securely store that is not a key.  While I could subvert the persistent key interface by importing and exporting data as persistent keys, that seems like a bad design choice.  The persistent storage feature does not store in internal flash which would add other security risks.

Either way I have been able to get my TF-M/PSA based approach to fit into nrf9160 on NCS 2.3.0 so i will close this ticket.

It seems the answers are:

* Zephyr ITS is broken and not officially supported.

* TF-M with ITS requires experimental support since its not included in the minimal configuration... therefore not officially supported 

* TF-M with ITS does seem to work including encryption but it requires a great deal of trial and error to get TF-M size reduced. 

* When reducing TF-M, from my experience, I recommend re-testing all important features after every KConfig change, I found that although sometimes I was able to compile I still sometimes encountered TF-M crashes or encountered certain errors only when a certain capability was tried at run time.

* TF-M crashes are really a pain to debug, there are no logs, and the debugger does not work if main of the non-secure app is not reached.