Hi,
I am working on an update from TF-M 1.8.1 to TF-M 2.1.1 on a board that uses encrypted Protected Storage. The board used is stm32 b_u585i_iot02a, NSPE side using Zephyr OS. I want to support field updates as well for devices already having Protected Storage objects created from NSPE. In my case, Protected Storage is created and used by TF-M 1.8.1, and I want it to remain functional after upgrading to TF-M 2.1.1. PS_CRYPTO_AEAD_ALG is set to (default) PSA_ALG_GCM.
I have faced two issues with the uplift:
1. It seems commit ffd13c3 ( https://github.com/TrustedFirmware-M/trusted-firmware-m/commit/ffd13c31d5e6f...) has changed the layout how Protected Storage objects are stored into flash. With TF-M 2.1.1 and old PS data, PS init fails (or gets recreated if PS_CREATE_FLASH_LAYOUT, which I don't want since then all the existing objects would get erased). If I revert the commit (and https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/... as not to have conflicts), then the PS initialization can pass and objects are decrypted successfully.
I have not been able to understand this thoroughly, but at least change in `union ps_crypto_t` struct member order is changing padding (sizeof 48 -> 40), and that in turn seems to shift at least additional data by 8 bytes via `#define PS_NON_AUTH_OBJ_TABLE_SIZE sizeof(union ps_crypto_t)`. Is this compatibility issue "a bug" in 2.1.1 or expected by design?
2. PS objects in 1.8.1 were storing client id to the object table entry to implement access control (?). With 1.8.1, the client id that got stored was -1. With 2.1.1, likely due to the Mailbox NS Agent Design Update ( https://tf-m-user-guide.trustedfirmware.org/design_docs/dual-cpu/mailbox_ns_...), non-secure requests to get an object seems to pass client ID -0x3c000000 to the Protected Storage implementation. That is, client id -1 seems to be transformed to `client_id_limit`. Due to this, `psa_ps_get_info()` fails to get an object that has been previously made with 1.8.1 FW.
I am able to get reading of old stored objects working by changing `client_id_limit` from value -0x3c000000 to -1 which changes to use 1-to-1 mapping when using client_id=-1. But I am unsure if this change causes some unwanted side effects. Is this the correct way to gain backwards compatibility? And if it is, would it make sense to pick https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git/... into 2.1.x branch and add a configuration flag for the 1-to-1 mapping support without code change for backwards compatibility?
Thanks, Miika