Hello Everyone,
We are currently working on TF-M for the firmware of our Cortex-M55 based core, part of a bigger platform
including a cortex-A based application processor, a bit like the corstone1000.
We use the RAM_LOAD boot mode of TF-M/MCUBoot and we want to implement an upgrade strategy based on
2 banks, and a switch to decide which bank to boot from. I have a few questions regarding some design choices.
I hope someone can answer them. Please correct me if some of my assumptions are wrong.
*
For the generic Firmware Upgrade partition, are there plans to support the RAM_LOAD mode ? Do you have
suggestions about what is missing or how it should be done ?
*
Currently, MCUBoot in RAM_LOAD mode only supports booting the slot with the highest version.
Do you think it is realistic to try and integrate another boot mode in MCUBoot that matches our needs ?
I'm asking this because I noticed that the corstone1000 platform has been developed working around
this limitation by changing the flash_map at platform initialization in order to abstract the problem from
MCUBoot completely.
Thank you and all the best,
Julien
Hi all,
I would like to know if the PSA ITS is protected in case tearing cases (power failure) happening during write/erase in the internal flash, using `psa_its_set()` or `psa_its_remove()`, please.
Thanks a lot.
Best regards,
Abel.
Could you please help with my issue? Thank you!
From: Michael Ji
Sent: Friday, February 14, 2025 4:15 PM
To: Raef.Coles(a)arm.com; Anton.Komlev(a)arm.com
Subject: TFM build error
Hi Raef and Anton:
I am following the steps in this webpage to build tfm on my Windows laptop:
https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht…
All my steps are successful till I ran this command below and got error (FYI - I am using the platform arm/mps2/an521 and GNU ARM compiler):
[cid:image001.png@01DB7EFB.878CE310]
Could you share your insight on how to resolve this? Thank you very much!
Best,
Michael
Hi all,
We would like to remove PSA_IOT_PROFILE_1<https://review.trustedfirmware.org/q/topic:%22remove-psa_iot_1%22> which is an early attestation token profile (used for the original
implementation of the PSA Initial Attestation service) and has been superseded by profile PSA 2.0.0
(https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#nam…).
The above patches include:
* Change the default token profile configuration to: ATTEST_TOKEN_PROFILE_PSA_2_0_0,
* Remove support for PSA_IOT_PROFILE_1.
Please let us know if you have any concerns, suggestions.
Best regards,
David Vincze
Hi,
I'm trying to add platform power control functions (to power off/on peripherials) to the SPM. Are there any examples of this? What is the cleanest way to implement? Can it be done via adding code to source/third_party/tfm/platform/ext/target/<vendor>/ and compiling into the platform_s target?
The diagram below says connection between SPM and PRoT partitions is IMPLEMENTATION DEFINED. How does the TF-M implement PRoT partitions to call the SPM? Can it be a direct API call? I did see platform_svc_handlers() but I assume that was for use by ARoT partitions (unpriviledged).
DEN0063 PSA Firmware Framework:
Some platforms include functionality that can only be accessed by firmware at the highest privilege level. For example, platform power control or control registers that are shared by secure and non-secure firmware. These Platform services must be implemented as part of the SPM, but the mechanism by which the NSPE firmware accesses these services is IMPLEMENTATION DEFINED.
[cid:image001.png@01DB7E32.B6F3B0D0]
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
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
