Hi all,
I just wanted to bring to your attention that TF-M has switched<https://review.trustedfirmware.org/q/topic:%22t_cose_upstream%22> to using the upstream t_cose library (which is used during creating and validating
attestation tokens). The main reason for this change is to remove the forked t_cose code from the TF-M repository, along with its maintenance needs
(similarly to the QCBOR library). Additionally, it will also allow us having consistent library code across all tf.org projects.
Under normal circumstances, this change should not have any impact on you – the library code is fetched automatically during build. It might happen
that you encounter CI failures in connection with this change, but you will only need to rebase your patches to align with the changes in the CI.
Best regards,
David Vincze
Hi All,
I have several questions. Thanks in advance for helping out.
1. I am trying to build a TF-M application for my platform with small profile with asymmetric signing module enabled. I tried using following command
cmake -S . -B build -G Ninja -DTFM_PLATFORM=MY/PLATFORM -DTFM_PROFILE="profile_small" -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y.
However, the asymmetric signing module is not included. More specifically, in trusted-firmware-m/secure_fw/partitions/crypto/crypto_asymmetric.c, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true.
From what I understand, the -DCRYPTO_ASYM_SIGN_MODULE_ENABLED=y only define the macro, but not set it to 1, therefore, the #if CRYPTO_ASYM_SIGN_MODULE_ENABLED is not true. I am wondering if there is any way I can enable -DCRYPTO_ASYM_SIGN_MODULE_ENABLED module while still staying in small profile. I am aware that the default CRYPTO_ENGINE_BUF_SIZE might not be enough and I am willing to override it with a command line flag. Preferably, I would not want to enable asymmetric module in config.cmake as I only want to enable it for one specific application.
1. If to build with Zephyr and have TF-M as a module, is there anyway to enable asymmetric signing module given a small profile (I actually care more about this question than first question)
1. Just out of curiosity, how do you use menuconfig in TF-M. I did try -DMENUCONFIG=ON, but the compiler complains
CMake Error at config/kconfig.cmake:31 (file):
file STRINGS file
"trusted-firmware-m/config/../platform/ext/target/MY/PLATFORM/preload.cmake"
cannot be read.
Call Stack (most recent call first):
config/kconfig.cmake:174 (convert_normal_cmake_config_to_kconfig)
CMakeLists.txt:26 (include)
I thought preload.cmake is no longer required.
Thank you very much!
Best regards,
Hao
Hi,
I noticed this FIXME note in platform_sp.c. Is it still valid? If so, why does it only work with Isolation level 1? I thought system reset is typically an NVIC register write and platform SP should be able to do that.
enum tfm_platform_err_t platform_sp_system_reset(void)
{
/* FIXME: The system reset functionality is only supported in isolation
* level 1.
*/
tfm_platform_hal_system_reset();
return TFM_PLATFORM_ERR_SUCCESS;
}
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi,
I'm doing a PoC on initial attestation for an university project using a
RP2350 board and I'm not really understanding why boot seed is stored in
OTP, shouldn't it be a value changing on each boot?
Pico SDK conveniently exposes one via a ROM function (rom_get_boot_random).
Another similar doubt I have is w.r.t. implementation id, couldn't it be
read from the board id (pico_get_unique_board_id)? Board id is factory
programmed in otp so it should actually be unique.
Best Regards,
Augusto Zanellato
Hi, is GCC 13.3 supported by the TFM build? Has anyone tried it? I see the documentation says v7.3.1+.
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
Hi Anton
Thank you for your response.
Let me break it down a bit.
1. We have several subsystems running on the non-secure side that require certain sensitive metadata to be stored in ITS.
2. Default values of ITS parameters are insufficient.
3. While building the Zephyr app with TF-M, NS-side (during build) passes these overriding values to CMake, which adds the specified preprocessor definitions to the compiler flags of TF-M, ensuring they are available during compilation.
4. Zephyr already has the harness for this flow.
This entire flow currently doesn’t work if we don’t explicitly use these preprocessors in TF-M CMake files.
Using a custom profile is not feasible for us because the overriding values are provided by the NS side based on their specific needs.
Additionally, even when we attempt to provide these parameters through the command line while building only TF-M (without NS-side), we encounter the same warning: "Manually-specified variables were not used by the project."
This warning indicates that these parameters are not being utilized in the CMake scripts (which make sense).
I guess the question would be is there a way to override these parameters from command-line, while being platform agnostic? If not, is there any specific reason we chose not to, other than this approach could potentially override the platform specific configuration, like you suggested?
We would appreciate any guidance or suggestions on how to properly handle this scenario. If needed, we can discuss this further in the next TF-M Tech forum, like you suggested.
Regards
Saurabh
On 1/24/25, 12:47 PM, "Anton Komlev via TF-M" <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi Saurabh,
If I understand you correctly, you're looking to modify the ITS_MAX_ASSET definition, which is a build-time option and cannot be changed post S-side build. Could you please explain your scenario for wanting to update it from the NS-side?
You're correct that a platform can redefine certain options which is intended behavior, allowing platforms to either override or verify these settings. For more details, you can refer to the TF-M configuration priorities here: https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html… <https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html…>.
The highest priority is the command line, which can override options even those defined in platforms. We should proceed cautiously with this approach, as there might be reasons why platforms alter the default configuration.
A recommended alternative is to create a custom profile and place all your options there, though some platforms might still overwrite them as expected.
We can discuss this further in the next TF-M Tech forum if you wish.
Hope that helps,
Anton
-----Original Message-----
From: Jain, Saurabh via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>>
Sent: Thursday, January 23, 2025 7:47 PM
To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Inquiry on Overriding ITS Parameters in TF-M via Zephyr
Hi All,
We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side.
Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning:
"Manually-specified variables were not used by the project."
As a result, the overrides are ignored.
Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific.
We would like to confirm:
1. Is there an existing platform-independent method to achieve such overrides that we may have missed?
2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms?
Looking forward to your input.
Best regards,
Saurabh
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>
Hi All,
We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side.
Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning:
"Manually-specified variables were not used by the project."
As a result, the overrides are ignored.
Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific.
We would like to confirm:
1. Is there an existing platform-independent method to achieve such overrides that we may have missed?
2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms?
Looking forward to your input.
Best regards,
Saurabh
Hello,
I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity.
Key Features:
* Offers Clang frontend
* Available for Linux, Windows and macOS
* Builds TF-M binaries for all Arm targets
* Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side
Important notes:
* Floating point support is not verified
* MVE is not supported yet
* This has been verified with version v18.1.3 of the toolchain.
We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains.
I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351
There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion.
Thanks, and best regards,
Anton.
Hi Everyone,
During our investigation into the slow write operations of the PSA Protected Storage (PS) API, we identified that numerous (>10) flash erase calls occur when executing psa_ps_set() or psa_ps_remove(). A significant portion of these erase calls is linked to the rollback protection mechanism, specifically for updating Non-Volatile (NV) counters.
A potential improvement we are considering is to differentiate rollback protection requirements based on the type of flash memory being used.
*
For systems utilizing internal flash, we suggest possibility to disable rollback protection when encryption is enabled. This improves speed of write and remove operations and reduces the flash wear.
*
Rollback protection should be enabled when protected storage is located in external flash to ensure data integrity and security
Currently, there is a Kconfig option, CONFIG_TFM_PS_ROLLBACK_PROTECTION, to disable rollback protection. However, a build-time check requires that PS encryption is also disabled, as referenced here:
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…
To better align rollback protection with the type of flash memory, there is the possibility of updating the macro rule. This could involve either removing the existing rollback protection check or adding a new rule based on the flash type, enforcing rollback protection only for external flash. While introducing a Kconfig option for the flash memory type is a potential solution, it raises concerns about reduced security in cases of misconfiguration.
Your insights on how to address this would be invaluable. Thank you in advance for your input!
Best regards,
Juha Ylinen
