Hi Archanaa
You can upgrade to the latest TFM.
These definitions were deleted by:
(05.06.2023)
SHA-1: 6abf39e6c3556af243f40b9dd0b36989150769db
* Crypto: Refine Mbedtls config
MBEDTLS_AES_SETKEY_DEC_ALT and MBEDTLS_AES_DECRYPT_ALT should be set in accelerator.
Best regards,
Andrej Butok
From: S Krishnan, Archanaa via TF-M <tf-m@lists.trustedfirmware.org>
Sent: Tuesday, October 3, 2023 12:43 AM
To: Antonio De Angelis <Antonio.DeAngelis@arm.com>; Summer Qin <Summer.Qin@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: [TF-M] 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