- TF-M - lists.trustedfirmware.org

ARMCLANG generates ELF with armv3m architecture

by Roman.Mazurak＠infineon.com

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.

1 year, 1 month

2
1
0 0

Improved linker files supporting TF-M isolation L1-3

by Jamie Fox

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

1 year, 1 month

2
1
0 0

Integrate TF-M and PSA Crypto API with PUFcc

by Andy Chen

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.--------

1 year, 2 months

2
1
0 0

Suggestion for unified logging library

by Jackson Cooper-Driver

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

1 year, 2 months

1
0
0 0

User interview sign up and information

by Lisa Durbin

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

1 year, 2 months

1
0
0 0

RFC: Remove specific section for psa_interface_thread_fn_call

by Nicola Mazzucato

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.

1 year, 2 months

1
0
0 0

Question about random number g

by Zhang, Hao

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

1 year, 2 months

2
2
0 0

Technical Forum call - July 7

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, July 7, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Link to the forum: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

1 year, 2 months

10
62
0 0

New to TF-M

by Michael Khoyilar

Hi all I am porting a new SoC to TF-M platform. I know I have missed something in my platform files that I am getting following error message, can someone please guide me. Thanks Built target manifest_tool [ 3%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/uart_stdout.o [ 4%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/nv_counters.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/flash_otp_nv_counters_backend.o [ 6%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/template/otp_flash.o [ 7%] Building C object platform/CMakeFiles/platform_s.dir/ext/common/provisioning.o [ 8%] Linking C static library libplatform_s.a [ 12%] Built target platform_s [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/service_api.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/spm/core/psa_interface_sfn.o [ 13%] Building C object secure_fw/partitions/lib/runtime/CMakeFiles/tfm_sprt.dir/__/__/__/__/interface/src/tfm_psa_call.o [ 14%] Linking C static library libtfm_sprt.a [ 17%] Built target tfm_sprt [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_boot_data.o [ 17%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/utilities.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch.o [ 18%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/main.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_ipc.o [ 19%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/rom_loader.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_call_api.o [ 20%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_version_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/psa_read_write_skip_api.o [ 21%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/backend_sfn.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_svcalls.o [ 23%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/tfm_pools.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/ns_client_ext/tfm_spm_ns_ctx.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/spm_local_connection.o [ 24%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/core/arch/tfm_arch_v8m_main.o [ 25%] Building C object secure_fw/spm/CMakeFiles/tfm_spm.dir/__/__/platform/ext/common/tfm_hal_nvic.o C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_enable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:5: warning: implicit declaration of function 'NVIC_EnableIRQ' [-Wimplicit-function-declaration] 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: error: 'IRQn_Type' undeclared (first use in this function) 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:21: note: each undeclared identifier is reported only once for each function it appears in C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:21:31: error: expected ')' before 'irq_num' 21 | NVIC_EnableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_disable': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:5: warning: implicit declaration of function 'NVIC_DisableIRQ' [-Wimplicit-function-declaration] 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:22: error: 'IRQn_Type' undeclared (first use in this function) 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:28:32: error: expected ')' before 'irq_num' 28 | NVIC_DisableIRQ((IRQn_Type)irq_num); | ~ ^~~~~~~ | ) C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c: In function 'tfm_hal_irq_clear_pending': C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:5: warning: implicit declaration of function 'NVIC_ClearPendingIRQ' [-Wimplicit-function-declaration] 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~~~~~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:27: error: 'IRQn_Type' undeclared (first use in this function) 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num); | ^~~~~~~~~ C:/trusted-firmware-m/platform/ext/common/tfm_hal_nvic.c:35:37: error: expected ')' before 'irq_num' 35 | NVIC_ClearPendingIRQ((IRQn_Type)irq_num);

1 year, 3 months

2
1
0 0

Re: Firmware Update: Storage Failure While Rejecting a Staged Image

by Cedric Klikpo

Hi Maulik, Thanks for your support. 1. I think I understand why you don’t get the error on the Musca-B1. In fact, we are not using the same flash driver: 1.1. My build uses the `emulated_flash_dvr`, which checks that the byte is erased in flash before attempting a write (this is where I get the error). 1.2. The Musca-B1 platform uses the `qspi_ip6514e_drv`, which does not perform such a check before writing to the flash. From what I understand, the MT25QL Series Flash NOR does not return an error even if you try to write a 1 in a bit that was 0. As such, you do not encounter the error. 2. It is strange that you don’t get the warning when MCUBOOT_CONFIRM_IMAGE=OFF. Best regards, Cédric

1 year, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M