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,
I want to bring community attention to a bug fix in build script for NS application:
In the original design we shall have a single CMake target 'tfm_api_ns' prepared and exported by SPE for building NSPE with consistent configuration. At some moment 2 extra targets 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' were introduced for different S-NS communication methods to be linked to tfm_api_ns on NS side. This created unnecessary NS dependency on SPE configuration and disallows creating NS application working with all platforms.
This patch is fixing the issue:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29005
Ideally, we should remove these redundant targets but that will break projects already adjusted and using them. There are 2 approaches to address the issue:
1. Preferred. Remove the targets and ask dependent projects for adjustment. (effectively, is 1 line change to stop linking to them).
2. Keep those targets as empty dummies for compatibility, polluting the code.
Please comment and object the removal (approach 1) if it's critical for your project. I would appreciate your feedback within 2 weeks to make the right decision.
Thanks,
Anton
Hello,
I followed this tutorial to add an example secure partition in TF-M ( https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_… ) and then followed these instructions to flash the application to my Nucleo-L552ZE-Q board ( https://tf-m-user-guide.trustedfirmware.org/platform/stm/common/stm32l5xx/r… ). However, the script regression.sh returned the error:
Error: Cannot connect to access port 0!
If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode.
If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it.
After this, I am unable to connect my board STM32Cube Programmer or to flash any application using Keil MDK ARM, CubeIDE, etc. The same error is returned every time. Before I runned the regression.sh script, the board was working as expected and I was able to flash simple applications (non using TF-M) to the board. I've already tried to connect the board to the STM32Cube Programmer using the Hot Plug mode - (i) pulled BOOT0 pin to HIGH, (ii) connected the board to the PC, (iii) selected Hot Plug mode in STM32Cube Programmer and Hit Connect - but did not work. I get this log:
[cid:20937ade-7ed2-4beb-bced-d577c3e58dd3]
Hi all,
Why does TFM assigns function to psa_interface_thread_fn_call section and then never places them anywhere specific?
This way functions assigned to this section are placed outside of the code region which may result in unpredictable behavior.
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>
Thanks Antonio! 😊
(fixed typo in subject, sorry ☹)
Thanks,
William
From: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>
Date: Wednesday, May 15, 2024 at 2:18 PM
To: "Lee, William" <William.Lee(a)garmin.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Subject: Re: Is crytocell-312 now maintaining by TF-M mainly?
Yes, CryptoCell code in the TF-M repo is the only maintained repository. Thanks, Antonio Sent from Outlook for Android From: Lee, William via TF-M <tf-m@ lists. trustedfirmware. org> Sent: Wednesday, May 15, 2024 5: 32: 59 am To: tf-m@ lists. trustedfirmware. org
Yes, CryptoCell code in the TF-M repo is the only maintained repository.
Thanks, Antonio
Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!Q29CY2id1…>
________________________________
From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Wednesday, May 15, 2024 5:32:59 am
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Is crytocell-312 now maintaining by TF-M mainly?
Hello!
I saw [1] is not updating anymore, but [2] is still active, anyone knows if [2] is the main place for cryptocell-312? Thanks!
[1] https://github.com/ARM-software/cryptocell-312-runtime<https://urldefense.com/v3/__https:/github.com/ARM-software/cryptocell-312-r…>
[2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai…<https://urldefense.com/v3/__https:/git.trustedfirmware.org/TF-M/trusted-fir…>
Thanks,
William
Hello,
I am happy to announce the new release of TF-M v2.1.0.
New major features are:
* TF-M aligns the Crypto service to the same PSA Crypto headers used by the Mbed TLS 3.6.0 reference implementation.
* Initial support for on-core and off-core clients on Hybrid platforms (A-profile + M-profile or M-profile + M-profile) using solution 1. The functionality is still under active development.
* P256-M component is enabled on the BL2 stage for image signature verification based on ECDSA.
* MCUboot upgrade to v2.1.0.
* Mbed TLS upgrade to v3.6.0.
* BL2 now provides a thin PSA Crypto core layer when MCUBOOT_USE_PSA_CRYPTO=ON and can use builtin keys when ECDSA based signature verification is selected with MCUBOOT_SIGNATURE_TYPE="EC-P256".
This version is the first, intended for Long Term Support (LTS) after PSA certification and tagging TF-Mv2.1.0-LTS as described in the updated Release Process.
Please check the release notes for more information.
The release branch changes will be ported to the main branch shortly.
Many thanks to everyone for contributing, reviewing and supporting this milestone.
Anton and TF-M team.
Hi
I am trying to use iatverifier tool from tf-m-tools repo to verify token and it seems like the values for Security Lificycle in the tool are wrong, because:
this spec https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-21.html defines them as
psa-lifecycle-unknown-type = 0x0000..0x00ff
psa-lifecycle-assembly-and-test-type = 0x1000..0x10ff
psa-lifecycle-psa-rot-provisioning-type = 0x2000..0x20ff
psa-lifecycle-secured-type = 0x3000..0x30ff
psa-lifecycle-non-psa-rot-debug-type = 0x4000..0x40ff
psa-lifecycle-recoverable-psa-rot-debug-type = 0x5000..0x50ff
psa-lifecycle-decommissioned-type = 0x6000..0x60ff
Which is consistent with values of tfm_security_lifecycle_t enum in TFM
enum tfm_security_lifecycle_t {
TFM_SLC_UNKNOWN = 0x0000u,
TFM_SLC_ASSEMBLY_AND_TEST = 0x1000u,
TFM_SLC_PSA_ROT_PROVISIONING = 0x2000u,
TFM_SLC_SECURED = 0x3000u,
TFM_SLC_NON_PSA_ROT_DEBUG = 0x4000u,
TFM_SLC_RECOVERABLE_PSA_ROT_DEBUG = 0x5000u,
TFM_SLC_DECOMMISSIONED = 0x6000u,
TFM_SLC_MAX_VALUE = UINT32_MAX,
};
But in the tf-m-tools/iat-verifier/iatverifier/psa_iot_profile1_token_claims.py these values are defined differently
# Security Lifecycle claims
SL_UNKNOWN = 0x1000
SL_PSA_ROT_PROVISIONING = 0x2000
SL_SECURED = 0x3000
SL_NON_PSA_ROT_DEBUG = 0x4000
SL_RECOVERABLE_PSA_ROT_DEBUG = 0x5000
SL_PSA_LIFECYCLE_DECOMMISSIONED = 0x6000
Thus I am getting SL_UNKNOWN instead of TFM_SLC_ASSEMBLY_AND_TEST
Is this a known issue? Can this be fixed?
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>
