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.
Hi TF-M teams,
This is Andy from PUFsecurity, and we have a project with ARM.
We try to integrate the PSA Crypto API with PUFcc (Our Crypto Engine) on TF-M.
However, there are multiple versions included, and we need your assistance for specification clarification.
Please ensure the versions match your recommendations.
For TF-M, we plan to integrate with:
TF-M v2.1.0
PSA Crypto API - v1.1.0
PSA Certified APIs Architecture Test Suite - v1.6
TF-M
It would be beneficial to use the same hardware (FPGA) and tools as the ARM development team.
If we can confirm which models are used for TF-M , scripts or details with the ARM hardware That would be grateful.
PSA Crypto API -
The test bench is using the PSA Crypto API v1.1.0, and it is published in 2022.
And Now is v1.2.1 in March 2024. I not sure it is a good choose or not.
[cid:983ad4d1-6d7d-4acb-a22d-5a49b94594d4]
Test Bench -
For the "PSA Certified APIs Architecture Test Suite - v1.6," we would like to identify which test codes (test_c001 to test_c067) are relevant for TF-M.
Thank you very much!!!
Have a Nice Day,
Andy
[cid:2fcb4633-c50b-4a64-8161-c5020f3b1ad3]
熵碼科技股份有限公司
Tel: 886-3-5601010 #2119
Email: andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>
Website: https://www.pufsecurity.com/
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
-------- Disclaimer: This e-mail is from PUFsecurity Corporation. This e-mail may contain privileged and confidential information. It is intended for the named recipient(s) only. Disclosure, copying, distribution, or use of the contents of this e-mail by persons other than the intended recipient may violate applicable laws. If you are not an intended recipient, please notify us immediately (by reply e-mail) and delete this e-mail from your system. Our postal address is 8F-1, No. 5, Tai-Yuan 1st St., Jhubei City, Hsinchu County 302082, Taiwan.--------
Hi all,
I would like to propose a unified logging library in TF-M. The primary aim of this is to combine the fragmented logging we have across TF-M into a single logging library, with a single top-level API. Currently, different components (BL1, SPM, secure partition, etc.) have different logging APIs and these also have different underlying implementations. Some call directly into the UART output string function and others call printf. Sometimes using one logging API in a different component leads to build failures, or nothing ending up on the UART at all.
The primary aim here is for users to be able to use the same API throughout TF-M and for it to always work. This API will naturally be split into different logging levels, with build configuration controlled whether or not the string is actually output. Note that the underlying implementation can be different for different components - there can be hooks within the library which allow components to specify how they want to output the string. Initially, these can be used to maintain the existing underlying implementation. In the longer term, however, it would be useful to unify the underlying implementation also whether that be by using printf or with our own custom printf format parser.
Please let me know any thoughts or concerns about the above suggestion.
Thanks,
Jackson
Hello everyone,
Thank you for giving us the opportunity to understand more about you and how we can design the technical information for your needs. For those who weren’t on the technical forum call today, here’s a summary of what these interviews are about:
We’re calling for volunteers to help us better understand who our users are and how we can improve your technical documentation journey. We’ll be conducting 45 minute – 1 hour interviews over Zoom to ask questions about your role, the tasks you perform, how you learn, and how you use our documentation. In today’s forum, Lisa Durbin (Principal Technical Content Developer) will run through the details about the interviews and how you can take part.
If you’re interested in taking part in the interviews, please do both of the following:
1. Fill out the consent form here on the Microsoft Forms site<https://forms.office.com/Pages/ResponsePage.aspx?id=eVlO89lXqkqtTbEipmIYTWl…>.
2. Book a 1 hour Zoom session with me here on the Office Bookings site.<https://outlook.office.com/bookwithme/user/5b86408b60db4f51ba9459930fbc64a3…>
Please note, I’m based in Cambridge UK and my availability is during BST office hours. I’ll be running the sessions starting July 8th until September 30th, 2024.
If you have any questions or would like further information, please feel free to email me directly. Thank you again for your help.
Kind regards,
Lisa Durbin
Lisa Durbin | Principal Technical Content Developer
She/her
CE-SW Technology Management team
Cambridge
Hi All,
I pushed for review a Request For Comments (RFC) patch where I remove specific attributes for sections introduced a while ago.
At that time, it was fixing an issue with Armclang builds.
However it has been noticed that with GCC, those functions are not placed within the .text section, as otherwise expected.
With the proposed RFC patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29755,
I ran a few tests and builds and the "old" issue with Armclang does not appear anymore and the functions are correctly placed within the .text section.
I would like to ask the community to cherry pick the patch and build & run their tests, to further verify that we are not breaking anything else.
If no issues are reported in a week or so, I will remove the RFC and then the patch will go through the final review.
Many thanks in advance for your cooperation.
Best regards,
Nicola Mazzucato (he/him/his) | CE Software group | Arm
110 Fulbourn Rd, CB1 9NJ, Cambridge UK
At Arm we work flexibly and globally, if you receive this email outside of your usual working hours please do not feel that you have to respond immediately.
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.
Hi TF-M and mbedtls community,
I am new to TF-M, I have a few questions about CryptoCell and random number generation. Thank you in advance.
1.
I figure there seems to have two CryptoCell 312 implementations within TF-M. One under lib/ext/cryptocell-312-runtime and the other under platform/ext/accelerator/cc312/cc312-rom. What are the difference between these two?
2.
For lib/ext/cryptocell-312-runtime, it does not define MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG whereas /ext/accelerator/cc312/cc312-rom does. Does that mean cryptocell-312-runtime is initiating RNG cryptodriver by using mbedtls_entropy_add_source whereas cc312-rom is using mbedtls_psa_external_get_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. If so, may I ask why these two cryptocells take two different approaches? I read from one of the documentation that mbedtls_psa_external_get_random is used when entropy is sufficient. So if entropy is sufficient, is it always preferred to have MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG defined and implements mbedtls_psa_external_get_random? What are the differences between the two approaches.
3.
I also found cryptocell-312-runtime defines the entry point function cc3xx_init_random<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>. But since PSA random number entry point funciton is not complete, the cc3xx_init_random is not being called anywhere, right?
[https://opengraph.githubassets.com/17cdebc400b0ed807c620b586b21f3f77ff9c5d3…]<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>
trusted-firmware-m/platform/ext/accelerator/cc312/cc312-rom/psa_driver_api/src/cc3xx_psa_random.c at 8df9cc8baf46252fd188bba1d87333a8daa9a5e8 · zephyrproject-rtos/trusted-firmware-m<https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/8df9cc8baf462…>
Zephyr repository tracking https://git.trustedfirmware.org/trusted-firmware-m.git/ - zephyrproject-rtos/trusted-firmware-m
github.com
4.
I know random number generation PSA entry point function is in development, may I ask when that would be expected to complete?
Thank you very much!
Best regards,
Hao
