Hi,
Just a reminder that the MCUboot version has been upgraded to v1.9.0<https://github.com/mcu-tools/mcuboot/releases/tag/v1.9.0> in TF-M. If you are using the local MCUboot repo, then you need to update it to that version to avoid build error.
Regards,
Sherry Zhang
Hi,
The next Technical Forum is planned on Thursday, March 17, 15:00-16:00 UTC (West time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hello,
TF-M release v1.6.0 will be shifted from April 15 to April 28. The main reason is Easter holiday and expected lack of availability from community and platform owners around that date. Feature freeze will be moved to April 6th when the release branch will be created.
Please update your plans accordingly.
Please let me know if this change make difficulty for you and better date is possible.
Thanks,
Anton
Hi all,
I want to simplify the flag TFM_PLATFORM in build system. TF-M now already supports two different ways to choose specific platform, for example AN521:
- Absolute path: '<tf-m path>/platform/ext/target/arm/mps2/an521'
- Relative path: 'arm/mps2/an21'
Recently I have uploaded a [tf-m patch]<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14260> to support platform name:
- Platform name: 'an521'
I think it will be more convenient for developers to use:
- Users don't need to remember and type the absolute or relative path, only target platform name is enough.
- If the structure of certain platform is changed, the default build command of TFM_PLATFORM is same.
I'd be very grateful if you can give any suggestion or enhancement for me. Thanks.
Best Regards
Jianliang Shen
Dear All,
I view the tf-m source code for the first time, and many of the code
details can not be make clear. So ..,
where may I find the design documents of spm, for example:
trusted-firmware-m-TF-Mv1.5.0\secure_fw\spm\cmsis_func and cmsis_psa
software modules.
Best Regards
Wang Zhilei | Software
Beken Corporation
----------------------------------------------------------------------------
---------------------------------------------------------
Hi,
The next Technical Forum is planned on Thursday, March 3, 7:00-8:00 UTC (Asian time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi colleagues!
Could we get a list of MISRA/CERT-C violations that were found by tf-m Coverity CI, as example from https://ci.trustedfirmware.org/job/tf-m-coverity/lastSuccessfulBuild/
Also (if it possible), could you provide Coverity configs to help align this tool setup on our side to CI and to check all changes before any pool requests?
Best regards,
Kostiantyn Tkachov
Cypress Semiconductor Ukraine
Firmware Security
Hello,
I am writing to you asking help because we are having problems when I try to compile the Trusted Firmware M from source code.
I downloaded the code from the official repository: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git
I moved to the last TAG: TF-Mv1.5.0
I am following this tutorial for PSOC64 platform https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/cypress/pso…
When I execute the first cmake command indicating the platform and the toolchain everything works well: cmake -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake ..
The problems appears when I build the code using the second cmake command: cmake --build cmake_build -- -j
I got this output
[cid:image003.jpg@01D82A77.95B43640]
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_verify':
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:145:5: error: conversion to non-scalar type requested
145 | verification_key_psa = (psa_key_handle_t)verification_key.k.key_handle;
| ^~~~~~~~~~~~~~~~~~~~
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_sign':
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:194:5: error: conversion to non-scalar type requested
194 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle;
| ^~~~~~~~~~~~~~~
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_sig_size':
/home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:245:5: error: conversion to non-scalar type requested
245 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle;
| ^~~~~~~~~~~~~~~
secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:425: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o' failed
make[2]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:1347: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all' failed
make[1]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all] Error 2
Makefile:135: recipe for target 'all' failed
make: *** [all] Error 2
There are the version of the software that are using:
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)
cmake version 3.23.0-rc2
It seems strange to me that there are compilation errors in the source code, that's why I am writing this mail, in case there is a bug in the code.
Best regards.
Antonio Javier Cabrera Gutierrez
Infineon Technologies AG
PhD Candidate
R&D Engineer
IFAG BEX RDE RDF ISS
Office: +49 89 234 36403
Mobile: +49 151 181 34322
AntonioJavier.CabreraGutierrez(a)infineon.com<mailto:AntonioJavier.CabreraGutierrez@infineon.com>
Am Campeon 1-15
85579 Neubiberg
Germany
www.infineon.com<http://www.infineon.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies>
Part of your life. Part of tomorrow.
Infineon Technologies AG
Chairman of the Supervisory Board: Dr. Wolfgang Eder
Management Board: Dr. Reinhard Ploss (CEO), Dr. Helmut Gassel, Jochen Hanebeck, Dr. Sven Schneider
Registered Office: Neubiberg
Commercial Register: München HRB 126492
This e-mail and any attachments are confidential. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. Any unauthorized use or disclosure may be unlawful. If you have received this e-mail by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it.
Hi all,
We are currently testing the tfm-m implementation on a STMicroelectronic chip: stm32u5 board.
This stm32u5 has a special register: SYSCFG_CSLOCKR (see https://www.st.com/resource/en/reference_manual/rm0456-stm32u575585-armbase…). This register allows to lock the PRIS bit of the AIRCR register from further modification.
The issue here is that, in the ST implementation, thanks to this SYSCFG_CSLOCKR, the PRIS bit of the AIRCR is locked at boot (Reset_Handler in file startup_stm32u5xx_s.c). Resulting in the function tfm_arch_set_secure_exception_priorities() not being able to set the PRIS bit of the AIRCR. This situation lead to big issues at runtime as interrupt priority of NSPE are able to pre-empt interrupt of SPE.
Disabling the locking of PRIS bit solve our problem but currently we don't see a clean way to integrate chip specific security features (something like callback/tfm_hal_ ) after the function tfm_arch_set_secure_exception_priorities() has been called.
What would be the best way to fix the current issue which could also arise on other platform ?
Regards,
Romain