Upgrading from Yocto Dunfell to Kirkstone causes secure storage device error

[bonifra-bh]

Good day

I hope someone can assist or point me in the right direction with an issue we are seeing when upgrading our field units from Yocto Dunfell (optee_os 3.20.0) to Kirkstone (optee_os 4.1.0). Secure storage created by the device when booted in the Dunfell rootfs, is not usable when booted into the Kirkstone rootfs. The /data/tee directory is located on a separate persistent partition. If the /data/tee directory is deleted when booted into Kirkstone and objects re-injected using pksc11-tool, all works fine. So there is nothing wrong with the installation or upgrade, there is just some fundamental difference between how objects are used between the two? The errors I am getting when the Kirkstone image is trying to access the secure storage is:

• ERR [3516] LT:ckteec_invoke_init:304: TEEC open session failed f0100001 from 3
• error: PKCS11 function C_Initialize failed: rv = CKR_DEVICE_ERROR (0x30)

On serial Debug:

• E/LD: init_elf:493 sys_open_ta_bin(fd02c9da-306c-48c7-a49c-bbd827ae86ee)
• E/TC:? 0 ldelf_init_with_ldelf:152 ldelf failed with res: 0xf0100001

It seems to be traceable to TEE_ERROR_CORRUPT_OBJECT originating from ldelf_init_with_ldelf:152 in core/kernel/ldelf_loader.c

As the devices in the field are currently using non-exportable keys inside their secure storage, it is necessary for the units to be able to use those same keys inside secure storage when upgraded.

Thanks

[jenswi-linaro]

As I said in https://github.com/OP-TEE/optee_os/issues/7138#issuecomment-2487837501, OP-TEE follows Semantic Versioning 2.0.0. So with an increased major version number, you expect some incompatibilities.

I recommend using git bisect to find the commit causing the problem. Once we know the commit it's easier to suggest a fix to the problem.

[jenswi-linaro]

I tested creating a few objects in secure storage with version 3.20.0 and then reading them on version 4.1.0, by running xtest n_1004 first on 3.20.0 and then on 4.1.0 on QEMU with a persistent secure storage directory. It worked as expected, except that I had to restart tee-supplicant with the persistent secure storage directory as an argument.

I suspect that it's something platform-specific, probably relating to the hardware-unique key.