That is meant as an optimization because the algorithms enabled in profile medium (e.g. AES_CCM) do not require to have the decryption functions of AES compiled in (in CCM decryption can be implemented through decryption). As Andrej mentions I believe the place in the source where those defines are set now has changed anyway if you update to a very latest version of TF-M development (i.e. they won't be defined in profile configs in the next release).

Thanks,
Antonio
From: S Krishnan, Archanaa <archanaask@ti.com>
Sent: Monday, October 2, 2023 23:42
To: Antonio De Angelis <Antonio.DeAngelis@arm.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: RE: Build error with customized mbedcrypto configuration
 

Antonio,

 

Thank you. In the medium profile, there are some ALT configrations such as MBEDTLS_AES_SETKEY_DEC_ALT and MBEDTLS_AES_DECRYPT_ALT that are enabled. If there is no alt layer implementation, these defines have to be commented out. Why does the medium config have such ALT configs enabled OOB?

 

Regards,
Archanaa

 

From: Antonio De Angelis <Antonio.DeAngelis@arm.com>
Sent: Friday, September 29, 2023 5:11 PM
To: S Krishnan, Archanaa <archanaask@ti.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] Re: Build error with customized mbedcrypto configuration

 

The buffer size depends essentially on two factors, which are the crypto APIs intended to be available, the algorithms enabled in the service backend and the size of the data to be processed per call, i.e. When operating on smaller chunks of data, the required allocations tend to be smaller. 

 

Current size (was) determined based on being able to pass PSA ACK tests which were taken as a sample of usage. But the size itself is meant to be configurable by platform integrators based on requirements. 

 

I brief, we don't recommend any particular size but I believe that could be determined by trial and error based on use cases. 

 

Thanks,

A\

 

Sent from Outlook for Android

From: S Krishnan, Archanaa <archanaask@ti.com>
Sent: Friday, September 29, 2023 7:14:19 PM
To: Antonio De Angelis <Antonio.DeAngelis@arm.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: RE: Build error with customized mbedcrypto configuration

 

Antonio,

 

Thank you. This was very helpful. With MBEDTLS_MEMORY_BUFFER_ALLOC_C, we are able to build secure image at this point.

 

Is there a recommended buffer size for the static buffers in mbedcrypto small/medium/large profile?

 

Regards,
Archanaa

 

From: Antonio De Angelis <Antonio.DeAngelis@arm.com>
Sent: Thursday, September 28, 2023 3:06 PM
To: S Krishnan, Archanaa <archanaask@ti.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] Re: Build error with customized mbedcrypto configuration

 

I believe at the time of v1.1, the linker scripts were still configured to allow heap memory, and that is something that changed in June 2022 (i.e. should be before TF-Mv1.6 was released if I am not mistaken). This should be (one of) the relevant patches: Platform: Remove unused heap (I6874d9a9) · Gerrit Code Review (trustedfirmware.org)

 

By design, the TF-M Crypto service has always been designed to use static buffers for memory allocation, although with the linker scripts before v1.6, it should have been quite simple to make it use the heap (i.e. by changing the config as you're trying to do here). Although we never explicitly decided to support this case because using a heap for allocation has deeper implications with higher level of isolation. By having the Crypto service working on a static buffer, you are sure that for every isolation level the allocations are private to the Crypto service memory.

 

platform_calloc_uninit() is just an example stubbed function that does nothing (i.e. uninitialized case). In TF-M case, we use the "buffer allocator feature" of Mbed TLS (i.e. MBEDTLS_MEMORY_BUFFER_ALLOC_C ) which is an alternative of providing your own platform specific implementation of calloc() and free(). If you want to use the static buffer allocator from mbed TLS, you can ignore those functions. If instead you want to provide your own static allocator, you need to override those two.

 

Hope this helps.

 

Thanks, Antonio

From: S Krishnan, Archanaa <archanaask@ti.com>
Sent: Thursday, September 28, 2023 20:16
To: Antonio De Angelis <Antonio.DeAngelis@arm.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: RE: Build error with customized mbedcrypto configuration

 

Hi Antonio,

 

Thank you. Has TF-M always used static buffers? We are migrating from TF-Mv1.1 to TF-Mv1.8. With v1.1, we were able to use calloc() calls from mbedcrypto for allocation slot for key storage.

 

Is there a sample platform_calloc_uninit() implementation (in mbedtls’ platform.c) that you could point me to that would use the static buffer for allocations/deallocations?

 

Regards,
Archanaa

 

From: Antonio De Angelis <Antonio.DeAngelis@arm.com>
Sent: Thursday, September 28, 2023 1:10 PM
To: Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org; S Krishnan, Archanaa <archanaask@ti.com>
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] Re: Build error with customized mbedcrypto configuration

 

Hi Archanaa,

 

from what I can see the behaviour is expected. You are using calloc() which assumes a heap is available but that is not the case in TF-M. The Crypto service is designed to use a static buffer over which allocations and deallocations happen. Any other behaviour has not been tested and likely requires some deeper reconfiguration of the Crypto service and TF-M linker scripts.

 

Thanks,

Antonio

From: S Krishnan, Archanaa via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, September 28, 2023 17:11
To: Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: [TF-M] Re: Build error with customized mbedcrypto configuration

 

Hi Summer,

 

Thank you for testing the build on your side. Yes, I have disabled MBEDTLS_MEMORY_BUFFER_ALLOC_C and other configurations that depend on MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C. Please see attached my modified medium profile and custom mbedcrypto configuration file (config-tidrivers.h).

 

It’s actually the linking phase, not build, during which I get the undefined reference to `end` error. A more detailed error message:

[ 97%] Linking C executable ../bin/tfm_s.axf

arm-none-eabi-gcc/11.2-2022.02-0/library-msp/ga/package/44fcf6b9a7fb86b2586303e3db40189d3b511830/bin/../lib/gcc/arm-none-eabi/11.2.1/../../../../arm-none-eabi/bin/ld: arm-none-eabi-gcc/11.2-2022.02-0/library-msp/ga/package/44fcf6b9a7fb86b2586303e3db40189d3b511830/bin/../lib/gcc/arm-none-eabi/11.2.1/../../../../arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end'

 

We include the mbedcrypoto custom configuration to the build using the following steps:

 

 

# Use mbedTLS conan package

MBEDCRYPTO_PATH = $(MBEDTLS_INSTALL_DIR)/source/third_party/mbedtls

 

# Add extra manifest list files and partition paths

TFM_EXTRA_OPTIONS = \

-DTFM_EXTRA_MANIFEST_LIST_FILES=$(PROJECT_PATH)/tfm_manifest_list.yaml \

-DTFM_EXTRA_PARTITION_PATHS=$(PROJECT_PATH)/

 

# Override default options with custom options and pass additional options

CONFIGURABLE_OPTIONS = \

-DTFM_MBEDCRYPTO_PLATFORM_EXTRA_CONFIG_PATH=$(MBEDCRYPTO_PATH)/ti/configs/config-tidrivers.h \

-DTFM_MBEDCRYPTO_PSA_CRYPTO_CONFIG_PATH=$(PROJECT_PATH)/config/psa_crypto_config.h \

-DPROJECT_CONFIG_HEADER_FILE=$(PROJECT_PATH)/config/config_profile.h \

-DTFM_PARTITION_INITIAL_ATTESTATION=False

 

all: generate configure build

 

# Include the common makefile, which defines the build targets

include $(SDK_INSTALL_DIR)/tfm_s/util/makefile_common.mak

 

 

 

Regards,
Archanaa

 

From: Summer Qin <Summer.Qin@arm.com>
Sent: Wednesday, September 27, 2023 9:56 PM
To: tf-m@lists.trustedfirmware.org; S Krishnan, Archanaa <archanaask@ti.com>
Cc: nd <nd@arm.com>
Subject: [EXTERNAL] Re: Build error with customized mbedcrypto configuration

 

Hi Archanaa,

 

By disabling MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C, you should also need to disable some other macros like MBEDTLS_MEMORY_BUFFER_ALLOC_C since mbedtls will do some dependency check.

I just used tfm default profile medium config to have a try, it can build successfully. 

Is it possible to show me your customized mbedcrypto configuration and build command? It will be helpful to know the issue you have ~

 

Best Wishes

Summer 

From: S Krishnan, Archanaa via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Thursday, September 28, 2023 6:04 AM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Build error with customized mbedcrypto configuration

 

Hello,

 

I am trying to build TF-M v1.8 with a custom tfm_mbedcrypto_config_profile_medium.h . I mainly do not want to use a platform specific calloc /free calls, instead use standard free() and calloc(). If I disable MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C in tfm_mbedcrypto_config_profile_medium.h and attempt to build TF-M, I get the following error:


/arm-none-eabi/lib/thumb/v8-m.main+fp/hard/libnosys.a(sbrk.o): in function `_sbrk':

/data/jenkins/workspace/GNU-toolchain/arm-11/src/newlib-cygwin/libgloss/libnosys/sbrk.c:21: undefined reference to `end'

 

I’m able to build mbedtls package with both MBEDTLS_PLATFORM_MEMORY and MBEDTLS_PLATFORM_C disabled without any errors, the undefined reference error is only seen when building TF-M.

 

Any thoughts on how to resolve this?

 

Regards,
Archanaa