- TF-M - lists.trustedfirmware.org

by Bohdan.Hunko＠infineon.com

Hi all, I am trying to build TFM with IAR with TFM_FIH_PROFILE=HIGH and I am facing the issue with the FIH labels. I see following errors: [ 98%] Linking C executable ../bin/tfm_s.axf Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_46_1"; in "main.o(libtfm_spm.a)", and "tfm_hal_platform.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_END_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" Error[Li006]: duplicate definitions for "FIH_LABEL_FIH_CALL_START_35_0"; in "tfm_hal_platform.o(libtfm_spm.a)", and "platform_svc_handler.o(libtfm_spm.a)" I did some investigations and I believe I know the root cause: Looks like __COUNTER__ for IAR is unique only for a translation unit (.c file) - thus when 2 files have FIH call in same line with the same number of FIH calls before - it creates a label which overlaps with labels in other file. For example tfm_hal_platform.c in our case has first FIH CALL in line 46 (which creates label FIH_LABEL_FIH_CALL_END_46_1) but main.c in our code also has first FIH CALL in line 46 which also results in FIH_LABEL_FIH_CALL_END_46_1 label. The question is - how can we solve this issue? Any ideas I can try? Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

2 months, 2 weeks

2
7
0 0

Upcoming TF-M Minor Releases: v2.1.4 and v2.2.2

by Anton Komlev

Hello, We're preparing two new minor releases: v2.1.4 and v2.2.2. Both releases update TF-M to include MbedTLS v3.6.5, which brings several vulnerability fixes and fix of the bug reported in v2.2.1. Following a successful dry-run test we'll publish Release Candidate (RC1) followed by the final release. As these are minor updates, we don't expect platform-specific testing, assuming the changes are platform-independent and that our CI coverage will be sufficient. However, please feel free to reach out if you have any concerns or foresee any platform impact. Thank you and best regards, Anton

2 months, 3 weeks

1
0
0 0

AI Policy - Guidance on AI-assisted contributions

by Shaun Longhorn

All, Please be aware that today we have published our AI policy with Guidance on AI-assisted contributions. See the full details here: https://www.trustedfirmware.org/aipolicy/ Should you have any questions feel free to raise them. Thanks, Shaun Community Manager

2 months, 3 weeks

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by jerome.forissier＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 months

1
0
0 0

Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 months

3
2
0 0

TF-M with Zephyr port of MCUboot

by Ozer, Sadik

Hi TF-M team, In our product, we intend to use the vanilla MCUboot (specifically the Zephyr port) instead of the version bundled with Trusted Firmware-M (TF-M). Since TF-M is optional for our use case, but MCUboot is a mandatory component, we prefer to decouple the two. Seems there are some provisioning related items that need to be handled in vanilla MCUboot for this type of usage. We would like to know if you foresee any security concerns or risks associated with this approach? Is this an expected of a usage? Any feedback for this type of usage would be appreciated. Thanks Sadik

3 months

2
1
0 0

Open CI testing infrastructure is currently experiencing issues

by Anton Komlev

Hello, The Open CI testing infrastructure is currently experiencing issues due to an FVP licensing problem. Image builds remain operational but FVP-based tests are failing, which causes all build jobs to be marked as failed. The Open CI team is actively working to resolve the issue. An update will be shared once normal operation is restored. Thanks, Anton

3 months

1
1
0 0

FIH code sharing

by Chris.Brand＠infineon.com

Hi, Currently TF-M and mcuboot have some "common" FIH code (see for example commit 0a74c1ea8a0c0783a2914d87cd2e88b677718a2e that copied fih.{c|h} from mcuboot. There are also multiple copies of fih.h within the TF-M repo (lib/fih/inc and bl2/ext/mcuboot/include). Are there any plans to avoid having copies of that code? Maybe to split the FIH library into its own repo that can be used by both TF-M and mcuboot? Thanks, Chris

3 months

2
1
0 0

Question on pka_ec_wrst_smul_scap.c in CryptoCell3xx Runtime

by Sato, Masaki

Hi TFM Developer Forum Organizer, I'm currently integrating the CryptoCell3xx Runtime code for ECDSA hardware acceleration and have a question regarding the implementation. I'm not entirely sure if this is the right list to post to - perhaps it belongs in mbed-tls or psa-crypto instead - so please forgive me and suggest the right list if this is not the appropriate forum. I noticed that the repository contains two variants of pka_ec_wrst_smul: one under no_scap and another under scap, located in /lib/ext/cryptocell-312-runtime/codesafe/src/crypto_api/pki/ec_wrst/. From the filenames and comments, it appears that scap.c is the Side-Channel Attack (SCA)-resistant version, and would therefore be preferred for end-user products where stronger security is prioritized over performance. However, in the current version of pka_ec_wrst_smul_scap.c from the main open-source branch, I found a couple of apparent typos/bugs that cause compilation errors: Line 239: should probably be PkaAddJcbJcb2Mdf(EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_TS, EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_X2, EC_SIGN_REG_T2, EC_SIGN_REG_Z2); (currently missing the leading "P".) Lines 389 and 391: the output parameters are declared as const, which seems incorrect. For example: CCError_t PkaEcWrstScalarMult(const CCEcpkiDomain_t *pDomain, /*!< [in] Pointer to EC domain. */ const uint32_t *scalar, /*!< [in] Pointer to the scalar buffer. */ uint32_t scalSizeInWords, /*!< [in] Size of the scalar in 32-bit words. */ uint32_t *inPointX, /*!< [in] Pointer to input point X coordinate. */ const uint32_t *inPointY, /*!< [in] Pointer to input point Y coordinate. */ const uint32_t *outPointX, /*!< [out] Pointer to output point X coordinate. */ The const qualifier on the output parameters seems unintended and rather for inPointX. Because of these issues, it seems this file might not have been recently reviewed or tested. So, my questions are: 1. Is the CryptoCell312 Runtime actively maintained and tested in a specific branch where these typos/bugs are already fixed? If so, could you please share which branch that is? 2. If not, it seems that CMake currently only selects the no_scap variant. Does this mean the scap variant is not actively maintained or tested, and therefore not recommended for production use due to higher risk? Thanks in advance for your help and clarification. Best regards, Masaki Sato (P.S. I have sent this message from proofpoint TFM list by "Start a new thread" button. However, I don't see a record on the "posting activity" under my account profile nor active discussion list. Pardon me, but I'm a newbie to this forum, so please forgive me to send the same message by email. ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

3 months, 1 week

3
3
0 0

Gerrit scheduled maintenance: 8th November 8-12 UTC

by saheer.babu＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 months, 1 week

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M