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
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.
Hello,
TF-M release v2.2.0 is unfortunately delayed for about a month.
The new tentative start date is the end of February with a goal to complete the release at the middle of March.
The main reasons of the delay are:
* Delays in PSA certification of RPi2350 platform
* An opportunity to accommodate of Mbed TLS v3.6.3 planned on February
* Limited availability of TF-M maintainers
Thanks, and sorry for the possible inconveniences caused be this delay,
Anton
Hi Anton
Thank you for your response.
Let me break it down a bit.
1. We have several subsystems running on the non-secure side that require certain sensitive metadata to be stored in ITS.
2. Default values of ITS parameters are insufficient.
3. While building the Zephyr app with TF-M, NS-side (during build) passes these overriding values to CMake, which adds the specified preprocessor definitions to the compiler flags of TF-M, ensuring they are available during compilation.
4. Zephyr already has the harness for this flow.
This entire flow currently doesn’t work if we don’t explicitly use these preprocessors in TF-M CMake files.
Using a custom profile is not feasible for us because the overriding values are provided by the NS side based on their specific needs.
Additionally, even when we attempt to provide these parameters through the command line while building only TF-M (without NS-side), we encounter the same warning: "Manually-specified variables were not used by the project."
This warning indicates that these parameters are not being utilized in the CMake scripts (which make sense).
I guess the question would be is there a way to override these parameters from command-line, while being platform agnostic? If not, is there any specific reason we chose not to, other than this approach could potentially override the platform specific configuration, like you suggested?
We would appreciate any guidance or suggestions on how to properly handle this scenario. If needed, we can discuss this further in the next TF-M Tech forum, like you suggested.
Regards
Saurabh
On 1/24/25, 12:47 PM, "Anton Komlev via TF-M" <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>> wrote:
Hi Saurabh,
If I understand you correctly, you're looking to modify the ITS_MAX_ASSET definition, which is a build-time option and cannot be changed post S-side build. Could you please explain your scenario for wanting to update it from the NS-side?
You're correct that a platform can redefine certain options which is intended behavior, allowing platforms to either override or verify these settings. For more details, you can refer to the TF-M configuration priorities here: https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html… <https://trustedfirmware-m.readthedocs.io/en/latest/configuration/index.html…>.
The highest priority is the command line, which can override options even those defined in platforms. We should proceed cautiously with this approach, as there might be reasons why platforms alter the default configuration.
A recommended alternative is to create a custom profile and place all your options there, though some platforms might still overwrite them as expected.
We can discuss this further in the next TF-M Tech forum if you wish.
Hope that helps,
Anton
-----Original Message-----
From: Jain, Saurabh via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>>
Sent: Thursday, January 23, 2025 7:47 PM
To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Inquiry on Overriding ITS Parameters in TF-M via Zephyr
Hi All,
We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side.
Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning:
"Manually-specified variables were not used by the project."
As a result, the overrides are ignored.
Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific.
We would like to confirm:
1. Is there an existing platform-independent method to achieve such overrides that we may have missed?
2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms?
Looking forward to your input.
Best regards,
Saurabh
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>
To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org <mailto:tf-m-leave@lists.trustedfirmware.org>
Hi All,
We are developing a platform using TF-M with Zephyr running on the Non-Secure (NS) side. As part of our requirements, we need to override certain ITS-related parameters, such as ITS_MAX_ASSET, from the NS side.
Zephyr provides a mechanism for this through Kconfig.tfm under modules/trusted-firmware-m, which includes symbols like TFM_ITS_MAX_ASSET_SIZE_OVERRIDE. When enabled, these configurations are passed to the TF-M build system via TFM_CMAKE_ARGS through CMake under modules/trusted-firmware-m. However, we observe that TF-M does not seem to support external overrides for these parameters. This results in the CMake warning:
"Manually-specified variables were not used by the project."
As a result, the overrides are ignored.
Currently, we address this by explicitly checking for external definitions of ITS_MAX_ASSET in platform-specific TF-M CMake files. While this works, it is platform-specific.
We would like to confirm:
1. Is there an existing platform-independent method to achieve such overrides that we may have missed?
2. If not, would the community be open to adding support for this functionality so it can be upstreamed and benefit other platforms?
Looking forward to your input.
Best regards,
Saurabh
Hello,
I am thrilled to announce the support of new Clan/LLVM toolchain, freely available here: https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm. This extends a suite of powerful tools designed to enhance your development experience and boost productivity.
Key Features:
* Offers Clang frontend
* Available for Linux, Windows and macOS
* Builds TF-M binaries for all Arm targets
* Secure side built without libc and picolib libraries, while both are available to Bootloader and Non-Secure side
Important notes:
* Floating point support is not verified
* MVE is not supported yet
* This has been verified with version v18.1.3 of the toolchain.
We're excited for you to try out the new toolchain support and look forward to your feedback. The use of the toolchain_CLANG.cmake is the same as all other toolchains.
I plan to present the new toolchain and compare it with the existing tools in one of the upcoming TF-M forums. Meanwhile I encourage the platform owners to include the new toolchain support using arm platforms as a reference. The relevant changes are in this chain:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34351
There is ongoing discussion on the best name for the toolchain to avoid possible confusion. Should it be Clang as now, LLVM, or even LLVMClang? Please share your opinion.
Thanks, and best regards,
Anton.
Hi Everyone,
During our investigation into the slow write operations of the PSA Protected Storage (PS) API, we identified that numerous (>10) flash erase calls occur when executing psa_ps_set() or psa_ps_remove(). A significant portion of these erase calls is linked to the rollback protection mechanism, specifically for updating Non-Volatile (NV) counters.
A potential improvement we are considering is to differentiate rollback protection requirements based on the type of flash memory being used.
*
For systems utilizing internal flash, we suggest possibility to disable rollback protection when encryption is enabled. This improves speed of write and remove operations and reduces the flash wear.
*
Rollback protection should be enabled when protected storage is located in external flash to ensure data integrity and security
Currently, there is a Kconfig option, CONFIG_TFM_PS_ROLLBACK_PROTECTION, to disable rollback protection. However, a build-time check requires that PS encryption is also disabled, as referenced here:
https://git.trustedfirmware.org/plugins/gitiles/TF-M/trusted-firmware-m.git…
To better align rollback protection with the type of flash memory, there is the possibility of updating the macro rule. This could involve either removing the existing rollback protection check or adding a new rule based on the flash type, enforcing rollback protection only for external flash. While introducing a Kconfig option for the flash memory type is a potential solution, it raises concerns about reduced security in cases of misconfiguration.
Your insights on how to address this would be invaluable. Thank you in advance for your input!
Best regards,
Juha Ylinen
Hi all,
When TF-M RPC callbacks were introduced to support multi-core mailbox handling, typically only a single mailbox interrupt source was available on a multi-core system.
Therefore, in the initial design, RPC callback handle_req(void) doesn't pass any information of mailbox interrupt source to platform mailbox drivers.
Recently, some platforms, such as RSE based ones, consists of multiple mailbox interrupt sources.
I notice that those platforms fetch and parse mailbox messages in their mailbox IRQ handlers. It can take quite a long time in IRQ handlers and doesn't get full benefits from Second-Level Interrupt Handling.
Due to the limitation of RPC callback handle_req(void), those platforms are unable to move mailbox message handling to threaded NS Agent Mailbox SP context.
I'd propose to add a new RPC callback handle_req_irq_src(irq_src) to pass mailbox interrupt source information to platform drivers. With this information, platform drivers can identify the source and select the corresponding handler to fetch, parse and dispatch mailbox messages in NS Agent Mailbox SP context, instead of in IRQ handlers.
If platform owners are all satisfied with this new RPC callback, I also wonder if it can replace the existing handle_req() in future, assumed no backward compatible issues are raised.
Please can you review the patches: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/34317/1?
Any comment is welcome. Thank you.
Best regards,
David Hu
