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.
--
Gilles Peskine
Mbed TLS developer and PSA Crypto architect
On 10/07/2023 10:48, Shebu Varghese Kuriakose via mbed-tls wrote:
>
> + 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.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...
>
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/crypto/crypto_library.c#n86
>
> 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
>
>
