Dear TF-M developers,
I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto.
At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite :
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/suit...
But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown.
And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called :
? -> mbedtls_platform_setup
? -> mbedtls_platform_teardown
At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem :
tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init
? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free
Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ?
If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/p...
or is there a nicer way of doing this ?
(btw, I am currently experimenting on qemu mps2-an521)
Thanks for any advice ! 🙂
Best regards,
Rehan MALAK Intrinsic ID
Hi Rehan,
This looks like a non-PSA standardized feature specific to mbed TLS. We don't have any platform in TF-M that requires such setup/teardown so I can't comment from experience, but to me it looks like this would be an mbed TLS specific feature that needs to be hooked underneath the service and into the library. The most natural choice would be indeed to have them as part of the psa_crypto_init() and lower functions, but at this stage I think is not possible to implement this without patching the source code (i.e. there are no options to allow this at build time in TF-M, at least).
Note also that mbed TLS has a on open ongoing issue to better define the initialisation sequence for the various operations in psa_crypto_init(): PSA: separate driver initialization with a nicer fixed ordering · Issue #6228 · Mbed-TLS/mbedtls (github.com)https://github.com/Mbed-TLS/mbedtls/issues/6228 It might be a good place to start to provide feedback regarding this particular aspect of custom platform initialisation if is not being considered there. To conclude, if you want to propose a patch for TF-M to allow such functions to be plugged in (in the meantime that mbed TLS agrees on the long term course of action), I will be happy to review it.
Thanks, Antonio
________________________________ From: Rehan Malak via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, July 7, 2023 13:15 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] mbedtls_platform_setup/teardown in TF-M ?
Dear TF-M developers,
I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto.
At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite :
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/suit...
But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown.
And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called :
? -> mbedtls_platform_setup
? -> mbedtls_platform_teardown
At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem :
tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init
? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free
Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ?
If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/p...
or is there a nicer way of doing this ?
(btw, I am currently experimenting on qemu mps2-an521)
Thanks for any advice ! 🙂
Best regards,
Rehan MALAK Intrinsic ID
Hi Antonio,
Thanks a lot for your answer !
Looking at the MbedTLS github link you sent (and the one therein)
- https://github.com/Mbed-TLS/mbedtls/issues/6228 PSA: separate driver initialization with a nicer fixed ordering
- https://github.com/Mbed-TLS/mbedtls/issues/6007 Define the PSA subsystem initialization interface in Mbed TLS
it seems that for the best would be indeed to provide feedback to the MbedTLS/PSA team such that TF-M could just run the adequate psa_* functions.
Thanks !
Rehan
Intrinsic ID ________________________________ From: Antonio De Angelis Antonio.DeAngelis@arm.com Sent: Saturday, July 8, 2023 12:13 AM To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Rehan Malak Rehan.Malak@intrinsic-id.com Subject: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?
Hi Rehan,
This looks like a non-PSA standardized feature specific to mbed TLS. We don't have any platform in TF-M that requires such setup/teardown so I can't comment from experience, but to me it looks like this would be an mbed TLS specific feature that needs to be hooked underneath the service and into the library. The most natural choice would be indeed to have them as part of the psa_crypto_init() and lower functions, but at this stage I think is not possible to implement this without patching the source code (i.e. there are no options to allow this at build time in TF-M, at least).
Note also that mbed TLS has a on open ongoing issue to better define the initialisation sequence for the various operations in psa_crypto_init(): PSA: separate driver initialization with a nicer fixed ordering · Issue #6228 · Mbed-TLS/mbedtls (github.com)https://github.com/Mbed-TLS/mbedtls/issues/6228 It might be a good place to start to provide feedback regarding this particular aspect of custom platform initialisation if is not being considered there. To conclude, if you want to propose a patch for TF-M to allow such functions to be plugged in (in the meantime that mbed TLS agrees on the long term course of action), I will be happy to review it.
Thanks, Antonio
________________________________ From: Rehan Malak via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, July 7, 2023 13:15 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] mbedtls_platform_setup/teardown in TF-M ?
Dear TF-M developers,
I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto.
At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite :
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/suit...
But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown.
And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called :
? -> mbedtls_platform_setup
? -> mbedtls_platform_teardown
At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem :
tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init
? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free
Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ?
If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/p...
or is there a nicer way of doing this ?
(btw, I am currently experimenting on qemu mps2-an521)
Thanks for any advice ! 🙂
Best regards,
Rehan MALAK Intrinsic ID
+ Mbed TLS mailing list for visibility…
Regards, Shebu
From: Rehan Malak via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, July 10, 2023 9:44 AM To: Antonio De Angelis Antonio.DeAngelis@arm.com; tf-m@lists.trustedfirmware.org Subject: [TF-M] Re: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?
Hi Antonio,
Thanks a lot for your answer !
Looking at the MbedTLS github link you sent (and the one therein)
- https://github.com/Mbed-TLS/mbedtls/issues/6228 PSA: separate driver initialization with a nicer fixed ordering
- https://github.com/Mbed-TLS/mbedtls/issues/6007 Define the PSA subsystem initialization interface in Mbed TLS
it seems that for the best would be indeed to provide feedback to the MbedTLS/PSA team such that TF-M could just run the adequate psa_* functions.
Thanks !
Rehan Intrinsic ID ________________________________ From: Antonio De Angelis <Antonio.DeAngelis@arm.commailto:Antonio.DeAngelis@arm.com> Sent: Saturday, July 8, 2023 12:13 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; Rehan Malak <Rehan.Malak@intrinsic-id.commailto:Rehan.Malak@intrinsic-id.com> Subject: [EXTERNAL] Re: mbedtls_platform_setup/teardown in TF-M ?
Hi Rehan,
This looks like a non-PSA standardized feature specific to mbed TLS. We don't have any platform in TF-M that requires such setup/teardown so I can't comment from experience, but to me it looks like this would be an mbed TLS specific feature that needs to be hooked underneath the service and into the library. The most natural choice would be indeed to have them as part of the psa_crypto_init() and lower functions, but at this stage I think is not possible to implement this without patching the source code (i.e. there are no options to allow this at build time in TF-M, at least).
Note also that mbed TLS has a on open ongoing issue to better define the initialisation sequence for the various operations in psa_crypto_init(): PSA: separate driver initialization with a nicer fixed ordering · Issue #6228 · Mbed-TLS/mbedtls (github.com)https://github.com/Mbed-TLS/mbedtls/issues/6228 It might be a good place to start to provide feedback regarding this particular aspect of custom platform initialisation if is not being considered there. To conclude, if you want to propose a patch for TF-M to allow such functions to be plugged in (in the meantime that mbed TLS agrees on the long term course of action), I will be happy to review it.
Thanks, Antonio
________________________________ From: Rehan Malak via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, July 7, 2023 13:15 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] mbedtls_platform_setup/teardown in TF-M ?
Dear TF-M developers,
I am currently adapting a basic MbedTLS / PSA Crypto example such that it would run on the NS side with TF-M doing the crypto.
At the end, this is very similar to this psa_sign_verify_message_test from the NS crypto test suite :
https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/suit...
But my build config of MbedTLS has MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT enabled because I have a custom mbedtls_platform_setup / mbedtls_platform_teardown.
And I can't see any place in TF-M where mbedtls_platform_setup/mbedtls_platform_teardown are called :
? -> mbedtls_platform_setup
? -> mbedtls_platform_teardown
At first, I tried to put this code into the psa_driver_wrapper_init/psa_driver_wrapper_free but I have a similar problem :
tfm_crypto_engine_init -> psa_crypto_init -> psa_driver_wrapper_init
? -> mbedtls_psa_crypto_free -> psa_driver_wrapper_free
Is there any cmake/Kconfig option or any C macros to hook TF-M initialization/shutdown with mbedtls_platform_setup/mbedtls_platform_teardown without patching TF-M ?
If not, could mbedtls_platform_setup be called here ? https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/p...
or is there a nicer way of doing this ?
(btw, I am currently experimenting on qemu mps2-an521)
Thanks for any advice ! 🙂
Best regards,
Rehan MALAK Intrinsic ID
Hello,
Mbed TLS's platform setup/teardown and driver init/free serve distinct, but overlapping purposes. Driver init/free is about a specific PSA driver. Platform setup/teardown is primarily about platform configuration, for example initializing a custom heap implementation on a base platform that doesn't provide malloc(), and also can be used to initialize ALT implementations (the pre-PSA equivalent of accelerator drivers). On some bare-metal platforms without an operating system, it can also be used as a general place for miscellaneous initialization, but that wouldn't apply to TF-M.
In TF-M, the secure world runs Mbed TLS to implement a PSA crypto service. TF-M needs to call psa_crypto_init() on the secure side to call driver initialization (amongst other things). TF-M can decide to support the customization of Mbed TLS's platform configuration or not; if it doesn't then I guess it doesn't need to call mbedtls_platform_setup.
Teardown/free functions exist for the sake of platforms that have an interface for clean shutdown. Embedded systems that are designed to run 24/7 except for power losses don't need to care about that.
Best regards,
tf-m@lists.trustedfirmware.org