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

Question

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?

Anthony Ambuehl · Accepted Answer

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.

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

Top Replies