HI Saurabh,
regarding points 1 and 2 which I guess are similar in nature, we effectively don't have currently any platform specific hooking during service initialization. But I reckon this is a general interesting feature to have (simply up to now we have had no platforms
requiring such personalized init) so I would welcome a contribution in this sense into the code if you're willing to provide it.
Regarding point 3, yes, that is correct, the final jump to NS happens when the initialization phase has completed, i.e. you can't receive requests before then from NS.
Hope this helps.
Thanks,
Antonio
From: Jain, Saurabh via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Wednesday, October 30, 2024 14:58
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Query on Storing OTP-Provisioned Values in ITS during Service Initialization
Hello
We have some platform-specific values provisioned in OTP that we need to retrieve and store in ITS (with encryption enabled) during initialization. We could do something similar to template file crypto_nv_seed.c, where the tfm_plat_crypto_provision_entropy_seed
function is invoked from tfm_crypto_engine_init within secure_fw/partitions/crypto/crypto_init.c. However, we have a few questions:
1. Adding something similar in tfm_its_init won’t work as psa_its_* would again call into ITS via SPM which could be a problem? Also there is no hook in its_init to add platform specific routines as well? Is this correct?
2. Since crypto_init.c is part of secure_fw/, we’re uncertain about adding new platform-specific routines directly in tfm_crypto_engine_init. If this is not advisable, could you suggest an ideal place for implementing this functionality?
3. Regarding the SFN model, our understanding is that SPM initializes all partitions (and their respective services) before transitioning control to the NS side. Could you confirm if this is correct? We want to make sure that the provisioned values are stored
in ITS before receiving request from NS client.
Thank you for your guidance!
Saurabh
--
TF-M mailing list -- tf-m@lists.trustedfirmware.org
To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org