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 all,
I am working on integrating our IP(PUFcc) into TF-Mv2.1.0, with the PUFcc located at address 0x51700000.
The PUFcc can be access on bl2 stage, however, it cannot be access on booting tf-m stage.
The exception log as below:
[cid:image002.png@01DAEFC7.96FE4EB0]FATAL ERROR: HardFault
Here is some context for the exception:
EXC_RETURN (LR): 0xFFFFFFF1
Exception came from secure FW in handler mode.
xPSR: 0x00000003
MSP: 0x31000B18
PSP: 0x31000BF8
MSP_NS: 0xFFFFFFFC
PSP_NS: 0xFFFFFFFC
Exception frame at: 0x31000B18
R0: 0x31000B60
R1: 0x00000000
R2: 0x0000001B
R3: 0x00000002
R12: 0x00000000
LR: 0x38009EF7
PC: 0x3800AB02
xPSR: 0x6100000B
Callee saved register state: R4: 0xFFFFFFF9
R5: 0x31000B60
R6: 0x00000002
R7: 0x00000002
R8: 0x38030F24
R9: 0x0000001B
R10: 0x00000011
R11: 0x38030F11
CFSR: 0x00008200
BFSR: 0x00000082
BFAR: 0x00000004
MMFSR: 0x00000000
MMFAR: Not Valid
UFSR: 0x00000000
HFSR: 0x40000000
SFSR: 0x00000000
SFAR: Not Valid
The diff patch as below:
[cid:image003.png@01DAEFC7.96FE4EB0]--- a/secure_fw/spm/core/main.c
+++ b/secure_fw/spm/core/main.c
@@ -56,6 +56,9 @@ static fih_int tfm_core_init(void)
*/
SPMLOG_INFMSG("\033[1;34mBooting TF-M "VERSION_FULLSTR"\033[0m\r\n");
+ uint32_t* p_s = (uint32_t *)0x51700000;
+ printf("p_s = %08x\n", (uint32_t)*p_s);
Could you provide any suggestions on this issue?
Best regards,
Mark Chen
Research & Development Division II
PUFsecurity Corporation
Tel: 886-3-5601010 ext. 3110
Fax: 886-3-5601177
Email: mark(a)pufsecurity.com<mailto:mark@pufsecurity.com>
[cid:image001.png@01DAEFC5.FD4AE270]
From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>
Sent: Thursday, August 1, 2024 12:12 AM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>>
Subject: Re: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform
Hi Anton,
Thank you and enjoy your time!!!
Best,
Andy
________________________________
寄件者: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
寄件日期: Wednesday, July 31, 2024 11:34:48 PM
收件者: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>
副本: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>; Antonio De Angelis <Antonio.DeAngelis(a)arm.com<mailto:Antonio.DeAngelis@arm.com>>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com<mailto:Shebu.VargheseKuriakose@arm.com>>
主旨: RE: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform
HI Andy,
Great to hear good news.
I will be in annual leave from tomorrow, Aug 1st, but Antonio (coped) could help you and can redirect the possible questions to appropriate team members.
With the occasion, I would appreciate if your team evaluates and follows TF-M documentation and gives us feedback on possible confusion or missing information.
Best regards,
Anton
From: Andy Chen <andychen(a)pufsecurity.com<mailto:andychen@pufsecurity.com>>
Sent: Wednesday, July 31, 2024 3:26 PM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: Randy Liu <randyliu(a)pufsecurity.com<mailto:randyliu@pufsecurity.com>>; Victor Huang <victor(a)pufsecurity.com<mailto:victor@pufsecurity.com>>; Neil Chen <neilchen(a)pufsecurity.com<mailto:neilchen@pufsecurity.com>>
Subject: [Technical Loop] PSA Crypto API with PUFcc on the TF-M platform
#Set a new mail loop
Hi Anton,
We set a kick-off meeting of "PSA Crypto API with PUFcc on the TF-M platform" this week.
• TF-M v2.1.0
• PSA Crypto API - v1.2.1
• PSA Certified APIs Architecture Test Suite - v1.6
• MPS3 with AN552
Randy, Victor, and Neil are members of this project.
We would have many issues when developing that need your help to solve it.
Please feel free to add your teams. Let's make the project successful.
Thank you very much.
Have a Nice Day,
Andy
[cid:image001.png@01DAEFC5.FD4AE270]
熵碼科技股份有限公司
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.--------
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.
-------- 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.--------
-------- 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.--------
Hello,
We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce:
1. Build TF-M secure image for CM33 platform with armclang (used 6.19).
2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers:
* arm-none-eabi-objdump -x tfm_s.axf
You will see following output:
tfm_s.axf
architecture: armv3m, flags 0x00000012:
EXEC_P, HAS_SYMS
While fromelf (from armclang) prints following:
========================================================================
** ELF Header Information
File Name: tfm_s.axf
Machine class: ELFCLASS32 (32-bit)
Data encoding: ELFDATA2LSB (Little endian)
Header version: EV_CURRENT (Current version)
Operating System ABI: none
ABI Version: 0
File Type: ET_EXEC (Executable) (2)
Machine: EM_ARM (ARM)
Image Entry point: 0x16004319
Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402)
ARM ELF revision: 5 (ABI version 2)
Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb.
Regards,
Roman.
Hi all,
I have pushed for review a change to improve the TF-M linker scripts / scatter files: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/30316
There are two ideas behind the change:
* Merge the isolation level 3 features from the tfm_isolation_l3 linker files into tfm_common_s, so that one linker file can support all TF-M isolation levels.
* Group the memory by its desired memory protection attribute as far as possible, so that as much of the memory map as possible can be covered by MPU regions to restrict the attributes to no more than needed. The main advantage of this is to reduce how much of the memory is executable.
There are more details in the commit message.
Since it could be a disruptive change, the new linker files are added in addition to the existing tfm_common_s.sct/ld/icf and tfm_isolation_l3.sct/ld/icf ones and only platforms that are already using the common tfm_hal_isolation_v8m.c are switched over for now. But the idea is that platforms can gradually migrate and eventually the existing linker files can be removed.
Kind regards,
Jamie
