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
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
Hi Antonio Thank you for the clarification, yeah, we would like to have something which could be added towards this requirement. I will try to open another thread to propose the design and get the feedback.
Regards Saurabh
From: Antonio De Angelis Antonio.DeAngelis@arm.com Date: Thursday, October 31, 2024 at 5:25 AM To: "tf-m@lists.trustedfirmware.org" tf-m@lists.trustedfirmware.org, "Jain, Saurabh" Saurabh.Jain@analog.com Subject: Re: Query on Storing OTP-Provisioned Values in ITS during Service Initialization
[External]
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
tf-m@lists.trustedfirmware.org
-
Antonio De Angelis -
Jain, Saurabh