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
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>
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
Hello,
The next Technical Forum is planned on Thursday, Sep 12 at 7:00-8:00 UTC (East 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 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
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
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