[TF-M] Re: Order of starting Secure Partitions

Hi,

The partitions would have to have a list of dependencies, so if your partition requires something from the Crypto one, the Crypto must in the list of deps of your partition and it will be initialised first.

Having said that, I believe the PSA_ERROR_INSUFFICIENT_MEMORY is being returned at some point by the API as Mbed TLS underneath might try to allocate some memory on the static allocator. The allocator is a buffer that is statically allocated in the TF-M Crypto partition and you can control its size by changing CRYPTO_ENGINE_BUF_SIZE at build time, the default is in:

❯ cat config_engine_buf.h /* * Copyright (c) 2023, Arm Limited. All rights reserved. * * SPDX-License-Identifier: BSD-3-Clause * */

#ifndef __CONFIG_ENGINE_BUF_H__ #define __CONFIG_ENGINE_BUF_H__

/* * CRYPTO_ENGINE_BUF_SIZE is decided by multiple components configs. * CRYPTO_ENGINE_BUF_SIZE can be overridden below by other component configs. * It must be guaranteed that this header file is included at last before CRYPTO_ENGINE_BUF_SIZE * is referred in crypto_library.c. * Otherwise, crypto_library.c may include an incorrect definition value. */

/* The CC312 needs at least 0x4000 of heap size to work properly */ #if defined(CRYPTO_HW_ACCELERATOR_CC312) && (CRYPTO_ENGINE_BUF_SIZE < 0x4000) #pragma message("CRYPTO_ENGINE_BUF_SIZE is redefined to 0x4000.") #undef CRYPTO_ENGINE_BUF_SIZE #define CRYPTO_ENGINE_BUF_SIZE 0x4000 #endif

#endif /* __CONFIG_ENGINE_BUF_H__ */

Different TF-M profiles might override this size with smaller (or bigger) sizes.

Hope this helps.

Thanks, Antonio

________________________________ From: Nicola Mazzucato via TF-M tf-m@lists.trustedfirmware.org Sent: Monday, June 02, 2025 12:07 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Florek, Bartlomiej bartlomiej.florek@assaabloy.com Subject: [TF-M] Re: Order of starting Secure Partitions

Hi Bartlomiej,

I am not sure I understood exactly the sequence you need to perform in your case, but have you perhaps tried to use the "tfm_hal_post_partition_init_hook"? In principle, you need to have the runtime initialization fully completed before you can require a secure service operation. Does your new partition need some crypto operations to initialize itself correctly? Which crypto api have you used exactly?

Best regards, Nicola

________________________________ From: Florek, Bartlomiej via TF-M tf-m@lists.trustedfirmware.org Sent: 02 June 2025 11:48 To: tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Subject: [TF-M] Order of starting Secure Partitions

Hello,

I'm trying to fit a new Secure Partition into Trusted Firmware - M environment. The current working environment consists of Zephyr RTOS 3.7 + TF-M 2.1.0 running under QEMU on MPS2 AN521 platform. General skeleton is in place - manifest with dependencies on TFM_CRYPTO, interface, IPC and handling communication. However, I have problems with using the PSA Crypto from the aforementioned new Service. I need a hash function, so I thought I'd use PSA Crypto API. The problem is that either the hash function or the initialization function (psa_crypto_init) is returning error (PSA_ERROR_INSUFFICIENT_MEMORY). I discovered that logs show PSA Crypto partition is loading after mine. This problem occurs in the entry_point function.

Is it possible to change the order of partitions loading or is there different mechanism advised to synchronize partition loading?

Thank you in advance for your suggestions.

Best regards,

Bartlomiej