- TF-M - lists.trustedfirmware.org

build warning with PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I noticed this build warning with PSA_FRAMEWORK_HAS_MM_IOVEC enabled. runtime_defs.h need to be updated to add the `const` qualifier I think. tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: warning: initialization of 'void * (*)(psa_handle_t, uint32_t)' {aka 'void * (*)(long int, long unsigned int)'} from incompatible pointer type 'const void * (*)(psa_handle_t, uint32_t)' {aka 'const void * (*)(long int, long unsigned int)'} [-Wincompatible-pointer-types] 287 | psa_map_invec_thread_fn_call, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: note: (near initialization for 'psa_api_thread_fn_call.psa_map_invec') Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 months

2
2
0 0

Start of TF-M v2.1.0 release

by Anton Komlev

Hi, We are starting the new TF-M release process on the branch release/2.1.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/+/refs/heads/re…> process and freezing the project features in it. RC1 tag will follow shortly. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

2 months

1
1
0 0

FW: Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

Hi Just forwarding older private discussion to mailing list to make it publicly available. 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> From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Sent: Thursday, December 14, 2023 15:57 To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com> Subject: Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Roman, I tried to look in the ELF spec that I could find by googling, but what I can find online doesn't mention the topic of alignment requirements at all other than a brief mention of how the base address and align requirements must be coherent. How the requirement on alignment propagates from sections to execution regions to load regions is still something that I am trying to understand as I can't find an exhaustive description. The info I shared below stem from a personal conversation that I had with the compiler team internally here in Arm, I have now asked for a reference, will revert back to you in case I get one. [cid:0aef50f0-9105-480f-8090-06cfaa06b8d3] Only explicit mention of alignment that I could find is in the armlink manual in section 3.3.3. [cid:ef5c45ef-7d67-433c-9aba-b8fd7cf0d1c0] The suggestion from the compiler team are as I mentioned: 1. just disable the strict checks on alignment (i.e. the linker will be then allowed to add padding as required to meet the constraint imposed by the base address of the load region and the ALIGN attributes, by suppressing the diagnostic or using --legacyalign (on a side note, I believe this is the default behaviour on GCC linker for example) 2. rewrite the scatter file to have all the input sections without alignment requirements in the output section where the vector reside, and then have another output section just after the first output section (i.e. with base address +0) to put all the other input sections with increased alignment. As a side note, the suggestion is to also align base addresses of sections using AlignExpr(+0, 4096) (for example, to align to 0x1000) rather than forcing ALIGN attributes. Note that this shouldn't be too complex to attain point 2 but it is something that at the moment we can't work on, but happily merge it in if you're willing to provide a patch for it. Your suggestion of having multiple output section is as well doable, but probably enough to have two of them. Will get back to you in case I get some more reference about how the alignment requirements in ELF propagate from input section to output sections just to confirm on the spec itself. Hope this helps, please let me know if any questions! Thanks, Antonio ________________________________ From: Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com> <Roman.Mazurak(a)infineon.com<mailto:Roman.Mazurak@infineon.com>> Sent: Thursday, December 14, 2023 13:37 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com> <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: RE: Weird behavior of Clang linker Hi Antonio, We have a use case when output section has following list of input sections: * Vectors with alignment by 0x400. * Partitions sections with alignment by 0x1000. As result output section alignment is 0x1000 and address is incorrect. So, probably it’s necessary to create a separate output section for each input section. Can you share a link to ELF specification with requirements for output section alignment? Best regards, Roman. From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, December 13, 2023 18:56 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>> Subject: [TF-M] Re: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, For reference, this is due to armlink being strict on following the ELF specification for which the region alignment is derived as the maximum alignment of the input sections. You can relax this requirement with armlink by either using the --legacyalign option (although it's being deprecated) or suppressing the diagnostic --diag_suppress=6244. In the future, we could try to reorganize the scatter file for the armclang toolchain to avoid using directly ALIGN attributes and align the base address of the execution regions using AlignExpr() instead, but even with this strategy, any alignment requirement which stems from using .aligned directive in assembly or attribute __ ((aligned)) attributes will influence the input sections alignment, hence it will require a deeper restructuring of the scatter file, possibly moving sections with increased alignment in a separate load region just after LR_CODE which must have a base address that forces a natural alignment. Hope this helps. Thanks, Antonio ________________________________ From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 13:39 To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Re: Weird behavior of Clang linker Hi Anton, Here is the version I am using: $ armclang --version Product: Arm Development Studio Gold Edition 2020.1 Component: Arm Compiler for Embedded 6.19 Tool: armclang [5e73cb00] Target: unspecified-arm-none-unspecified 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> From: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Sent: Monday, December 11, 2023 15:34 To: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: Weird behavior of Clang linker Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Bohdan, What is Clang version you are using? Thanks, Anton From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, December 11, 2023 12:58 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Weird behavior of Clang linker Hi all, Our platform uses 4KBs alignment in linker files (as this is the requirement of our protection HW). For this reasons I have introduced tfm_s_linker_alignments.h. Everything works fine with GCC but we have a problem with Clang. The problem is that Clang requires LR_CODE to have same alignment as other sections inside of it. Following are the steps to reproduce the issue: 1. Set TFM_LINKER_DEFAULT_ALIGNMENT to 0x1000 in tfm_s_linker_alignments.h 2. Build AN521 with following command line cmake -S . -B build_an521 -DTFM_PLATFORM=arm/mps2/an521 -DTFM_TOOLCHAIN_FILE=./toolchain_ARMCLANG.cmake Expected result: Everything works fine Actual result: Error: L6244E: Load region LR_CODE address (0x10080400) not aligned on a 4096 byte boundary. This error is weird because there is no explicit alignment assigned to LR_CODE region. Would appreciate a help on this as it is a blocking issue for us. 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> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

2 months, 3 weeks

1
0
0 0

TF-M OpenCI issue in lava_test

by Anton Komlev

Hello, TF-M OpenCI fails all LAVA tests and all builds are fail consequently, probably because of a new license mechanism. An investigation and problem fixing are ongoing. I will update you when the problem will be resolved. Best regards, Anton

2 months, 3 weeks

1
1
0 0

Security Vulnerability Notice - Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms

by Antonio De Angelis

Hi Everyone, There is a new security vulnerability discovered on the PSA Driver API for CryptoCell enabled platforms, described as "Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms". Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process [1] below : * TF-M Security advisory: TFMV-6: Add cc3xx_partial_tag_compare_on_chacha20_poly1305 advisory (I44bc426f) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22995> * Patch to fix the issue has been already merged on master branch as commit https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=2e82… * TF-Mv1.8.1 will be released in the next days containing the same hotfix Please let us know if you have any comments. Best regards, /Antonio [1] https://developer.trustedfirmware.org/w/collaboration/security_center/report...<https://developer.trustedfirmware.org/w/collaboration/security_center/repor…>

2 months, 3 weeks

2
1
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Antonio De Angelis

Hi Ruchika, thanks for your email and apologies for the late reply but I did not receive this directly so I am replying only because I was pointed to this. TF-M would really welcome a contribution to move those drivers to the autogen framework. This has not been done yet due to lack of bandwidth on TF-M side. Would like to note that the TF-M builtin key loader driver can't be (maybe, just completely) moved to the autogen framework because it patches some internals of Mbed TLS as well (i.e. you would need to patch the jinja template as well). But the CC3XX driver is absolutely something that we would like to move to the autogen framework without any issue. Thanks, Antonio

2 months, 3 weeks

2
1
0 0

Upcoming TF-M release heads up.

by Anton Komlev

Hello, We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th. Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze. Thanks, Anton

2 months, 3 weeks

1
1
0 0

TF-M support for Mbed TLS 3.6.0-LTS

by Antonio De Angelis

Hi all, Mbed TLS 3.6.0-LTS has been recently released and we are in the process of upgrading the supported version of TF-M as well. I have prepared three patches (for tests, extras and the main repo) available here for review that need to be merged by the time the release freeze happens (likely this week at some point). From this patch onwards, TF-M will align completely to the PSA Crypto headers shipped by the Mbed TLS project, hopefully solving the issues we have had in the past around header mismatches when both Mbed TLS and TF-M Crypto are integrated into the same environment. For this reason the TF-M project will just hold a copy of the headers (in the interface/include/psa and interface/include/mbedtls directories) and won't accept any contribution to them. Please find the patches available for review under the following Gerrit topic: topic:"mbedtls_3_6_0_alignment" · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22mbedtls_3_6_0_alignment%22> Thanks, Antonio

2 months, 3 weeks

1
0
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

+ tf-m mailing list From: Ruchika Gupta Sent: Friday, April 5, 2024 4:14 PM To: tf-m <"tf-m(a)lists.trustedfirmware.org <tf-m"@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org; security-wg(a)lists.zephyrproject.org Subject: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

2 months, 3 weeks

2
1
0 0

MCUBOOT_SWAP_USING_MOVE vs MCUBOOT_SWAP_USING_SCRATCH

by Tomasz Jastrzębski

Hi All, I apologize for this probably trivial question, but I cannot find out if and why I should use MCUBOOT_SWAP_USING_MOVE or MCUBOOT_SWAP_USING_SCRATCH. Are there any real advantages of move with SCRATCH other than that it requires less flash? - that is, min just one extra sector for all the images vs min one sector per image? Move without scratch seems to provide a better wear balance but still almost all the examples I come across use move with scratch. What am I missing? Kind regards, Tomasz

2 months, 4 weeks

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M