- TF-M - lists.trustedfirmware.org

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, 3 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, 3 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, 3 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, 4 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, 4 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, 4 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, 4 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, 4 months

1
0
0 0

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

by Maulik Patel

Hello Cedric, I built with both MCUBOOT_CONFIRM_IMAGE=OFF (default config for musca b1) and MCUBOOT_CONFIRM_IMAGE=ON and in both cases, I do not get any error/warning. Running Test Suite PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)... > Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionity test.' TEST: TFM_NS_FWU_TEST_1001 - PASSED! > Executing 'TFM_NS_FWU_TEST_1002' ... Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 13 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 13 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Jun 2024 14:06:16 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Re: Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171820117605.1175.3411332003376446357(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi Maulik, Sorry, I forgot to mention that I got the error when the image is built with the option "MCUBOOT_CONFIRM_IMAGE" enabled. When, when this option is not enable, I do not get the error, and the FWU test status is PASSED. However, the test is marked as passed with the following warning, which clearly states that the testcase is skipped: ``` Executing 'TFM_NS_FWU_TEST_1001' Description: 'Functionality test.' The component isn't in READY state: the device is not ready to run FWU tests, skip FWU test: 1. TEST: TFM_NS_FWU_TEST_1001 - PASSED! ``` So, I would like to confirm with you: 1. When you enable the option "MCUBOOT_CONFIRM_IMAGE," does your TFM_NS_FWU_TEST_1001 testcase pass? 2. When you disable the option "MCUBOOT_CONFIRM_IMAGE," do you get the same warning? Best regards, Cédric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 13 ************************************

1 year, 4 months

1
0
0 0

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

by Maulik Patel

Hello Cedric Unfortunately we only have musca b1 support for FWU at the moment. However as you mentioned, I did try TFM version 1.8.0 on commit *35ac80c85 and all tests (secure and non-secure including FWU) passes without any issues. Best Regards, Maulik

1 year, 4 months

2
1
0 0

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

by Maulik Patel

Hello Cedric, I tried the FWU tests on musca b1 platform and all of them passes without any failures. Could you please provide more context on specific version/commit or platform where you encounter PSA_ERROR_STORAGE_FAILURE? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 07 June 2024 1:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 68, Issue 6 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Firmware Update: Storage Failure While Rejecting a Staged Image (cedric.klikpo(a)scalinx.com) ---------------------------------------------------------------------- Message: 1 Date: Thu, 06 Jun 2024 13:00:29 -0000 From: cedric.klikpo(a)scalinx.com Subject: [TF-M] Firmware Update: Storage Failure While Rejecting a Staged Image To: tf-m(a)lists.trustedfirmware.org Message-ID: <171767882935.438215.6657950002748011855(a)lists.trustedfirmware.org> Content-Type: text/plain; charset="utf-8" Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric ------------------------------ Subject: Digest Footer TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ------------------------------ End of TF-M Digest, Vol 68, Issue 6 ***********************************

1 year, 4 months

2
1
0 0

API_DISPATCH for tfm_crypto_api.c

by Quach, Brian

Hi, I noticed that trusted-firmware-m\interface\src\tfm_crypto_api.c defines two API_DISPATCH macros for psa_call(). It is used most of the time in the file, but I still see ~10 instances where psa_call() is used. Can it be changed to consistently use the API_DISPATCH macros. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 4 months

2
2
0 0

PSA Cryptoprocessor Driver Interface

by Zhang, Hao

Hi TF-M community, TF-M allows Semiconductor vendors to plug in their HW accelerator using PSA cryptoprocessor driver interface. I have a couple of questions in terms of the driver interface. 1. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS using driver interface, for the multipart operation, https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa… states that "A driver that implements a multi-part operation must define all of the entry points in this family as well as a type that represents the operation context." Take aead encrypt as an example, if the underlying hardware does not support aead_abort, could it implements aead_abort by simply return PSA_ERROR_NOT_SUPPORTED? 2. The driver interface depends heavily on psa_crypto_driver_wrappers.h to dispatch operations to customized HW accelerator, where the psa_crypto_driver_wrappers.h file is automatically generated by scripts/data_files/driver_templates/psa_crypto_driver_wrappers.h.jinja. To port customized HW accelerator to TF-M's Crypto service for TF-M v2.1.0 LTS, would the approach be creating a customized psa_crypto_driver_wrappers.h.jinja file, the driver description file in JSON, and entry point functions. If so and we are considering upstreaming TF-M in the future, all these files would go inside platform/ext/accelerator/<vendor name>. Efforts need to be made so files such as psa_crypto_driver_wrappers.h.jinja should point to mbedtls, right? Additionally, as .jinja is retiring (mentioned in another email exchange), how would semi vendors update psa_crypto_driver_wrappers.h in the future? [https://opengraph.githubassets.com/c87e79773a7fb0841ea038f7cf3dfdf4170debb8…]<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls/docs/proposed/psa-driver-interface.md at zephyr · zephyrproject-rtos/mbedtls<https://github.com/zephyrproject-rtos/mbedtls/blob/zephyr/docs/proposed/psa…> mbedtls module for Zephyr, this is not a mirror of the official mbedtls repository. - zephyrproject-rtos/mbedtls github.com Thank you very much! Best regards

1 year, 4 months

4
9
0 0

Firmware Update: Storage Failure While Rejecting a Staged Image

by cedric.klikpo＠scalinx.com

Hi, I encounter a storage failure when trying to reject a staged image. I get this error by executing `tfm_fwu_test_common_001` in `fwu_tests_common.c`. The error occurs when the `erase_boot_magic` function attempts to erase the magic number in the image trailer by writing erase into it. The reason I am writing this post is to ask: 1. If the `erase_boot_magic` failure is a known bug in the firmware update, is a fix planned or existing? 2. Why doesn't the `erase_boot_magic` function erase the sector where the magic number is located in the image trailer, considering we erasing in a flash? Thanks! Best regards, Cedric

1 year, 4 months

1
0
0 0

Remove 'tfm_api_ns_tz' and 'tfm_api_ns_mailbox' targets

by Anton Komlev

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

1 year, 5 months

1
0
0 0

help - error in regression.sh using STM Nucleo-L552ZE-Q

by Miguel Costa

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]

1 year, 5 months

1
0
0 0

psa_interface_thread_fn_call section

by Bohdan.Hunko＠infineon.com

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>

1 year, 5 months

2
4
0 0

Re: Is cryptocell-312 now maintaining by TF-M mainly?

by Lee, William

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

1 year, 5 months

2
1
0 0

Is crytocell-312 now maintaining by TF-M mainly?

by Lee, William

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 [2] https://git.trustedfirmware.org/TF-M/trusted-firmware-m/+log/refs/heads/mai… Thanks, William

1 year, 5 months

2
1
0 0

TF-M release v2.1.0 announcement

by Anton Komlev

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.

1 year, 5 months

1
0
0 0

Wrong Life Cycle values in iatverifier

by Bohdan.Hunko＠infineon.com

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>

1 year, 6 months

3
3
0 0

Isolation Level 2/3 IO vector access

by Quach, Brian

Hi, For Isolation Level 2, ARoT cannot access PRoT data. If PRoT partition makes a call to ARoT partition, how are the input/output buffers made accessible to the ARoT partition so a transient copy of the data can be made? I looked at the AN521 implementation of tfm_hal_activate_boundary() and it does add any MPU regions to allow unprivileged access under Isolation Level 2. For Isolation Level 3, I assume the input/output buffers would need to added to a runtime memory asset to allow unprivileged access. Is my understanding correct? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 6 months

2
1
0 0

psa_unmap_invec

by Quach, Brian

Hi, I see that tfm_crypto_call_srv() unmaps output vectors if PSA_FRAMEWORK_HAS_MM_IOVEC == 1, but I never see psa_unmap_invec called. This doesn't seem to be required from a functional standpoint but I was wondering if psa_unmap_invec() was purposely skipped to save some unnecessary execution time. Is psa_unmap_invec() only implemented for testing purposes? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 6 months

2
1
0 0

build warning with PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I noticed this build warning with PSA_FRAMEWORK_HAS_MM_IOVEC enabled. runtime_defs.h need to be updated to add the `const` qualifier I think. tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: warning: initialization of 'void * (*)(psa_handle_t, uint32_t)' {aka 'void * (*)(long int, long unsigned int)'} from incompatible pointer type 'const void * (*)(psa_handle_t, uint32_t)' {aka 'const void * (*)(long int, long unsigned int)'} [-Wincompatible-pointer-types] 287 | psa_map_invec_thread_fn_call, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tfm/secure_fw/spm/core/psa_interface_thread_fn_call.c:287:33: note: (near initialization for 'psa_api_thread_fn_call.psa_map_invec') Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 6 months

2
2
0 0

Start of TF-M v2.1.0 release

by Anton Komlev

Hi, We are starting the new TF-M release process on the branch release/2.1.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/+/refs/heads/re…> process and freezing the project features in it. RC1 tag will follow shortly. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

1 year, 6 months

1
1
0 0

TF-M OpenCI issue in lava_test

by Anton Komlev

Hello, TF-M OpenCI fails all LAVA tests and all builds are fail consequently, probably because of a new license mechanism. An investigation and problem fixing are ongoing. I will update you when the problem will be resolved. Best regards, Anton

1 year, 6 months

1
1
0 0

Security Vulnerability Notice - Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms

by Antonio De Angelis

Hi Everyone, There is a new security vulnerability discovered on the PSA Driver API for CryptoCell enabled platforms, described as "Partial tag comparison when using Chacha20-Poly1305 on the PSA driver API interface in CryptoCell enabled platforms". Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process [1] below : * TF-M Security advisory: TFMV-6: Add cc3xx_partial_tag_compare_on_chacha20_poly1305 advisory (I44bc426f) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/22995> * Patch to fix the issue has been already merged on master branch as commit https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=2e82… * TF-Mv1.8.1 will be released in the next days containing the same hotfix Please let us know if you have any comments. Best regards, /Antonio [1] https://developer.trustedfirmware.org/w/collaboration/security_center/report...<https://developer.trustedfirmware.org/w/collaboration/security_center/repor…>

1 year, 6 months

2
1
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Antonio De Angelis

Hi Ruchika, thanks for your email and apologies for the late reply but I did not receive this directly so I am replying only because I was pointed to this. TF-M would really welcome a contribution to move those drivers to the autogen framework. This has not been done yet due to lack of bandwidth on TF-M side. Would like to note that the TF-M builtin key loader driver can't be (maybe, just completely) moved to the autogen framework because it patches some internals of Mbed TLS as well (i.e. you would need to patch the jinja template as well). But the CC3XX driver is absolutely something that we would like to move to the autogen framework without any issue. Thanks, Antonio

1 year, 6 months

2
1
0 0

Upcoming TF-M release heads up.

by Anton Komlev

Hello, We plan to initiate TF-M v2.1.0 release with a feature freeze on April 8th targeting completion before April 28th. Please let me know if there are pending patches critical to be included in this release and shall be merged before the feature freeze. Thanks, Anton

1 year, 6 months

1
1
0 0

TF-M support for Mbed TLS 3.6.0-LTS

by Antonio De Angelis

Hi all, Mbed TLS 3.6.0-LTS has been recently released and we are in the process of upgrading the supported version of TF-M as well. I have prepared three patches (for tests, extras and the main repo) available here for review that need to be merged by the time the release freeze happens (likely this week at some point). From this patch onwards, TF-M will align completely to the PSA Crypto headers shipped by the Mbed TLS project, hopefully solving the issues we have had in the past around header mismatches when both Mbed TLS and TF-M Crypto are integrated into the same environment. For this reason the TF-M project will just hold a copy of the headers (in the interface/include/psa and interface/include/mbedtls directories) and won't accept any contribution to them. Please find the patches available for review under the following Gerrit topic: topic:"mbedtls_3_6_0_alignment" · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/q/topic:%22mbedtls_3_6_0_alignment%22> Thanks, Antonio

1 year, 6 months

1
0
0 0

Re: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file

by Ruchika Gupta

+ tf-m mailing list From: Ruchika Gupta Sent: Friday, April 5, 2024 4:14 PM To: tf-m <"tf-m(a)lists.trustedfirmware.org <tf-m"@lists.trustedfirmware.org>; mbed-tls(a)lists.trustedfirmware.org; security-wg(a)lists.zephyrproject.org Subject: Use of auto-generation approach for mbedtls/mbed-crypto driver psa_crypto_driver_wrappers..h file Hi All, Apologies for the long email. I am adding all the 3 projects (TF-M, mbedTLS and Zephyr) to the mail chain because the issues I discuss below are inter-connected and affect all the three projects. From mbedtls 3.5.0 version, the mbedtls project has migrated to auto-generated psa_crypto_driver_wrappers.h file. https://github.com/Mbed-TLS/mbedtls/blob/development/docs/psa-driver-exampl… https://github.com/Mbed-TLS/mbedtls/blob/development/docs/proposed/psa-driv… On TF-M, mbed-crypto, there are 2 patches for the drivers given below which are still hardcoding their changes and not following the above approach. 1. PSA_CRYPTO_DRIVER_TFM_BUILTIN_KEY_LOADER (0001-Add-TF-M-Builtin-Key-Loader-driver-entry-points.patch) 2. PSA_CRYPTO_DRIVER_CC3XX (0005-Hardcode-CC3XX-entry-points.patch) We at NXP, have migrated our psa crypto wrappers to the above approach using auto-generation. We want to maintain same code base for mbedtls for our SDK's, TFM mbed-crypto as well as align mbedTLS fork in Zephyr. We are increasingly finding it difficult to migrate to newer versions of mbedtls because of hardcoding of above drivers. The problem is specially on the Zephyr front, where in the mbedTLS fork in zephyr these patches from tfm are applied by default. I have queries for all the 3 projects listed below : TF-M --> Can you please let us know what are the plans to migrate these 2 drivers in tfm to the auto-generation approach. If these patches can be migrated to make changes in jinja files rather than hardcoding in psa_crypto_driver_wrappers , things would be much easier to integrate. Is somebody already working on it ? Are you open to accept patches for this change ? mbedTLS --> What is the long term strategy from mbedTLS on this auto-generation ? We still have a lot of hard-coding in .jinja file rather than using drivers.json. Would mbedTLS/new PSA crypto repository start accepting patches for psa wrappers from platforms ? Can the patches which TF-M project maintains be merged in the mbedTLS ? Zephyr --> On Zephyr front, what are the plans to align to this auto-generation approach ? Regards, Ruchika

1 year, 6 months

2
1
0 0

MCUBOOT_SWAP_USING_MOVE vs MCUBOOT_SWAP_USING_SCRATCH

by Tomasz Jastrzębski

Hi All, I apologize for this probably trivial question, but I cannot find out if and why I should use MCUBOOT_SWAP_USING_MOVE or MCUBOOT_SWAP_USING_SCRATCH. Are there any real advantages of move with SCRATCH other than that it requires less flash? - that is, min just one extra sector for all the images vs min one sector per image? Move without scratch seems to provide a better wear balance but still almost all the examples I come across use move with scratch. What am I missing? Kind regards, Tomasz

1 year, 6 months

2
2
0 0

Windows 10 error file name or extension too long

by Michael Khoyilar

Hi all I am new to TF-M and want to know if there is a public forum to post questions or search for answers? I am getting this error under Windows 10 when making clean: make (e=206): The filename or extension is too long Thank you Michael

1 year, 7 months

4
3
0 0

Please unsubscribe

by Kirill Konevets

Unsubscribe me please

1 year, 7 months

3
2
0 0

TF-M Tech forum time update proposal

by Anton Komlev

Hi, Following the forum session today I am sending this separate email asking for your feedback. The recent forums on the East time zone slot are getting quite low attendance, so I am wondering if it still valuable or we want to reschedule it. The potential options I can think of: 1. Keep the current schedule and change nothing. 2. Drop the East time zone slot and leave West time zone slot only for monthly meetings. 3. Reschedule slots for bi-weekly forums on West time zone. 4. Other ideas? Thanks, and please share your opinion in this email thread, Anton

1 year, 7 months

1
0
0 0

NS Client ID mapping for Hybrid Platform

by Mate Toth-Pal

Hi All, As part of the work we are doing for Hybrid Platforms we prepared a patch that makes changes how the Non-Secure Client IDs are handled. When TF-M is run in Hybrid Platform configuration, It has multiple NS agents active the same time. Each of the NS clients (either running in the NSPE the same v8M CPU as SPM, or on the other end of a Mailbox) can have their own way to assign NS Client IDs to clients. To prevent NS clients impersonate other NS clients that are accessing secure services through a different agent, the patch introduces Client ID mapping. For each NS agent partition a range of valid Client IDs is defined in the manifest yaml file. The SPM checks boot time that the ranges don't overlap. The NS agent partitions must make sure that they map incoming client ID's in a way that the output Client ID is always in the range of valid IDs for that NS agent. If an NS agent has multiple mailboxes, it is possible to assign separate ranges for those mailboxes (the range is associated with the Mailbox IRQ in the manifest yaml). Please find the patch here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/26947 Any questions or comments are welcome! Best Regards, Mate

1 year, 7 months

1
0
0 0

Nordic nRF9160 bootloader gets stuck because of undefined function

by Boeckmann, Lena

Hi folks, I tried running a minimal example on the nRF9160dk. In `boot_hal_bl2.c` the following code is executed: #ifdef FLASH_DEV_NAME result = FLASH_DEV_NAME.Uninitialize(); if (result != ARM_DRIVER_OK) { while(1) {} } #endif /* FLASH_DEV_NAME */ For the Nordic boards `Uninitialize` is not implemented (see `Driver_Flash.c`): ARM_DRIVER_FLASH Driver_FLASH0 = { .GetVersion = NULL, .GetCapabilities = ARM_Flash_GetCapabilities, .Initialize = ARM_Flash_Initialize, .Uninitialize = NULL, .PowerControl = NULL, .ReadData = ARM_Flash_ReadData, .ProgramData = ARM_Flash_ProgramData, .EraseSector = ARM_Flash_EraseSector, .EraseChip = NULL, .GetStatus = NULL, .GetInfo = ARM_Flash_GetInfo }; This leads to a non-zero value being stored in `result` and my program ends up getting stuck in the while loop. Is it possible to fix that? Kind regards, Lena

1 year, 7 months

1
0
0 0

Re: Scheduling bug

by Roman.Mazurak＠infineon.com

Hi Ken, I tested with 2.0.0 release. There are my conclusions. tfm_arch_set_context_ret_code set result (for psa_wait, ...) by using SP stored in sp member of context_ctrl_t structure. It means that before calling tfm_arch_set_context_ret_code TF-M should update SP for thread (partition). thrd_next update result by calling tfm_arch_set_context_ret_code, if query_state_cb (pointing to query_state implemented by backend_ipc.c) returns THRD_STATE_RET_VAL_AVAIL. For all partition except active (interrupted by PendSV) context (values in context_ctrl_t) is correct. But context is invalid for active partition, because it is updated by PendSV after exit from ipc_schedule and thrd_next. As result call for psa_wait would fail if some secure IRQ will update signals_asserted after tfm_spm_partition_psa_wait and before PendSV will call thrd_next. SLIH interrupt can assert such signal (call to backend_assert_signal) in spm_handle_interrupt. I made a simple fix: diff --git a/secure_fw/spm/core/backend_ipc.c b/secure_fw/spm/core/backend_ipc.c index 3a968a3..c8b0742 100644 --- a/secure_fw/spm/core/backend_ipc.c +++ b/secure_fw/spm/core/backend_ipc.c @@ -454,9 +454,14 @@ /* Protect concurrent access to current thread/component and thread status */ CRITICAL_SECTION_ENTER(cs); - pth_next = thrd_next(); p_curr_ctx = (struct context_ctrl_t *)(CURRENT_THREAD->p_context_ctrl); + /* Update SP for current thread, so tfm_arch_set_context_ret_code can use up to date + * value of stack context to return value via R0.*/ + p_curr_ctx->sp = __get_PSP() - sizeof(struct tfm_additional_context_t); + + pth_next = thrd_next(); + AAPCS_DUAL_U32_SET(ctx_ctrls, (uint32_t)p_curr_ctx, (uint32_t)p_curr_ctx); p_part_curr = GET_CURRENT_COMPONENT(); Regards, Roman. From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, November 8, 2023 22:22 To: Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd(a)arm.com<mailto:nd@arm.com> Subject: [TF-M] Re: Scheduling bug 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 Ken, I was using 1.8.0 Release Looks like this issue was fixed in new design although we would like to test it and confirm this when we migrate to newest release. We will get back on this to you. 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: Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, November 7, 2023 03:58 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Re: Scheduling bug 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, Can you share us the version you are working on? Looks like the patch is based on a previous version of TFM, and this issue is resolved in the latest code base. The reason to do such abstraction is just because of such similar issues - the logic was coupled tightly because of synching the partition status, thread status and context update which caused maintenance confusion and effort. And we refactored this part to decouple the logic: SPM: Add STATUS_NEED_SCHEDULE to manage scheduler (21054) * Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21054> Hope this helps, thanks. /Ken From: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Monday, November 6, 2023 10:01 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Scheduling bug Hi There seem to be scheduling bug we have found in SPM. This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition. Steps to reproduce: 1. Call psa_wait() from partition (e.g. mailbox partition) 2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this ) 3. Following sequence happens: * Mailbox IRQ has lower priority than SVC thus SVC is not preempted. * SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending) * SVC triggers pendSV i. Mailbox IRQ and pendSV are both pending * Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed * Mailbox IRQ calls spm_handle_interrupt i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV) * Mailbox IRQ return, pendsv is started and it runs mailbox partition i. Mailbox partition has 0 as signal because return value was written to wrong location is stack Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix( Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...) 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>

1 year, 7 months

2
3
0 0

SPM thread and FLIH

by Roman.Mazurak＠infineon.com

Hi all, It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread. 1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource. Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread. Regards, Roman.

1 year, 7 months

3
5
0 0

Adding platform support for ArmChina Alcor AN557 MPS3 board

by jidong.mei＠armchina.com

Hi I'm working on Adding Platform support for ArmChina Alcor AN557 MPS3 FPGA board . The code has been passed tfm_regression_test on AN557 fpga image and now submit to TF-M git repo. See: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/27267 Could you have a code review on these code ? Any comments and suggestion are welcomed. Thank you! B,R Jidong

1 year, 7 months

1
0
0 0

New TF-M maintainer

by Anton Komlev

Hi Everyone, I am glad to announce the new maintainer of TF-M project: * Antonio de Angelis aka adeaarm Antonio.deAngelis(a)arm.com><mailto:Antonio.deAngelis@arm.com%3e%60> Antonio was with TF-M from the very beginning being one of the project founders. Thank you, Antonio, for agreeing to maintain the project. All the best, Anton

1 year, 7 months

1
0
0 0

Image verification by 'untrusted client'

by Tomasz Jastrzębski

Is TFM-M currently able to verify the signature of the image downloaded by the 'untrusted client'? I mean, are there needed methods exposed to 'untrusted app'? If so, what methods need to be used? Kind regards, Tomasz

1 year, 7 months

1
0
0 0

tf-m main branch (latest commit) compiler error ,when build regression_test for corstone300/an547

by jidong.mei＠armchina.com

Hi I encounter a compile error , with latest main branch tf-m code. Code version : "commit 66c8eada12737f5cf6818ea84739f30ca275437d (HEAD -> main, origin/main, origin/HEAD) Author: Raef Coles <raef.coles(a)arm.com>" Build targert : corstone300/an547 regression_test Build command : cmake -S spe -B build_spe -DTFM_PLATFORM=arm/mps3/corstone300/an547 -DCONFIG_TFM_SOURCE_PATH=<tf-m_path> -DTFM_TOOLCHAIN_FILE=<tf-m_path>/toolchain_GNUARM.cmake -DTEST_S=ON -DTEST_NS=ON -DCMAKE_BUILD_TYPE=Debug & cmake --build build_spe -- install (these command fellow the build_test documentation : https://tf-m-user-guide.trustedfirmware.org/building/tests_build_instructio…) Compile error : "trusted-firmware-m/platform/ext/target/arm/mps3/corstone300/an547/cmsis_drivers/Driver_Flash.c:23:10: fatal error: tfm_hal_device_header.h: No such file or directory #include "tfm_hal_device_header.h" " Could you help to fix this issue. B,R Jidong

1 year, 7 months

3
2
0 0

ITS encryption

by Quach, Brian

Hi, It appears that ITS encryption would be required for PSA Certified Level 3. I'm seeing that this would required a platform specific HAL implementation. Is there some reason PSA Crypto APIs were not used like they were for attestation? Encryption in ITS ================= The ITS can optionally be configured to encrypt the internal trusted storage data. To support encryption in ITS the target platform must provide an implementation of the APIs defined in ``platform/include/tfm_hal_its_encryption.h``:: enum tfm_hal_status_t tfm_hal_its_aead_generate_nonce(uint8_t *nonce, const size_t nonce_size); enum tfm_hal_status_t tfm_hal_its_aead_encrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *plaintext, const size_t plaintext_size, uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size); enum tfm_hal_status_t tfm_hal_its_aead_decrypt( struct tfm_hal_its_auth_crypt_ctx *ctx, const uint8_t *ciphertext, const size_t ciphertext_size, uint8_t *tag, const size_t tag_size, uint8_t *plaintext, const size_t plaintext_size); Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 8 months

3
5
0 0

Build without re-downloading packages?

by Tomasz Jastrzębski

Hi All, Since ST platform seems to be supported only passively, I try to adapt tf-m for the new ST U5Axx and U5Gxx MPUs with 4MB flash on my own. It does not come easy since some things are hardcoded and new HAL version is required while breaking HAL changes have been introduced, but this is not the reason why I make this post. Is there any easy way, I mean, some cmake switch, which would allow for a full rebuild without redownloading the required packages? Since clean rebuild from scratch takes time and I need to do it frequently while my Internet connection currently is not super-fast and stable such option would be the most helpful. Kind regards, Tomasz

1 year, 8 months

2
1
0 0

Re: Attest token v2.0 in psa-arch-tests

by Maulik Patel

Hello Bohdan The PSA token spec v2.0 is still in draft and hence is not yet supported by the psa-arch-tests. I am not aware of the specific plan/timelines, but could you please contact psa-arch-tests team to know details? Best Regards, Maulik ________________________________ From: tf-m-request(a)lists.trustedfirmware.org <tf-m-request(a)lists.trustedfirmware.org> Sent: 27 February 2024 12:00 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: TF-M Digest, Vol 64, Issue 12 Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. Re: Attest token v2.0 in psa-arch-tests (Bohdan.Hunko(a)infineon.com) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Feb 2024 10:50:38 +0000 From: <Bohdan.Hunko(a)infineon.com> Subject: [TF-M] Re: Attest token v2.0 in psa-arch-tests To: <tf-m(a)lists.trustedfirmware.org> Cc: Kostiantyn.Tkachov(a)infineon.com, Roman.Mazurak(a)infineon.com, Hennadiy.Kytsun(a)infineon.com Message-ID: <be7dcff9aa504e3f894b7f4fd263512d(a)infineon.com> Content-Type: multipart/alternative; boundary="_000_be7dcff9aa504e3f894b7f4fd263512dinfineoncom_" Hi all, Any updates on this? 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: Bohdan.Hunko--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, February 19, 2024 15:24 To: tf-m(a)lists.trustedfirmware.org Cc: Tkachov Kostiantyn (CSS ICW SW FW) <Kostiantyn.Tkachov(a)infineon.com>; Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak(a)infineon.com>; Kytsun Hennadiy (CSS ICW SW FW 3) <Hennadiy.Kytsun(a)infineon.com> Subject: [TF-M] Attest token v2.0 in psa-arch-tests 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 all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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>

1 year, 8 months

1
0
0 0

Attest token v2.0 in psa-arch-tests

by Bohdan.Hunko＠infineon.com

Hi all, I was trying to run PSA arch tests for INITIAL_ATTESTATION and have some problems with them. Our platform uses version 2.0 of PSA token spec (ATTEST_TOKEN_PROFILE_PSA_2_0_0) - https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-20.txt but psa arch tests does not seem to support it. Am I correct that psa-arch-tests does not support v2.0 of attest token? If yes, then how do I select v2.0 of attest token? If no, then is there a plan to support v2.0 of attest token in psa-arch-tests? If so then what is a release date for that? 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>

1 year, 8 months

1
1
0 0

Unable to determine default CMAKE_INSTALL_LIBDIR directory

by Quach, Brian

Hi, I'm seeing this warning when running cmake from a conan pkg: `/home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/bin/cmake -S . -B build -DTFM_PLATFORM=arm/mps2/an521`. Does anyone know how to fix it? I see the language is set by `project("Trusted Firmware M" VERSION ${TFM_VERSION} LANGUAGES C CXX ASM)`. Per-partition files done: CMake Warning (dev) at /home/brian/.conan/data/cmake/3.21.3-0/library-msp/ga/package/be241241e9d4718e5bab4eb33935bbb69606bb0c/share/cmake-3.21/Modules/GNUInstallDirs.cmake:236 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): build/lib/ext/mbedcrypto-src/CMakeLists.txt:42 (include) This warning is for project developers. Use -Wno-dev to suppress it. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 8 months

2
1
0 0

There are many kinds

by bpqp9ny2＠nqmo.com

Car Mishaps is often harrowing experiences, leaving victims addressing physical injuries, emotional trauma, and financial burdens. In this sort of demanding occasions, owning the right lawful representation might make all the primary difference. When you are in Austin, Texas, and end up wanting legal support following a car accident, https://www.canadatopescorts.com

1 year, 8 months

1
0
0 0

STM32l562e_dk platform is excluded from LAVA tests being a blocker for TF-M builds

by Anton Komlev

Hello, STM32l562e dk platform is timing out in LAVA tests which fails all TF-M builds. The platform was excluded from tests temporarily to enable normal development progress. Best regards, Anton

1 year, 8 months

1
0
0 0

Re: STM target - HAL version upgrade?

by Tomasz Jastrzębski

Hi Ahmad, Thank you for the confirmation. To be honest, I did not expect good news. Kind regards, Tomasz From: Ahmad EL JOUAID <ahmad.eljouaid(a)st.com> Sent: Wednesday, February 7, 2024 3:04 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl> Cc: tf-m-request(a)lists.trustedfirmware.org; Stephane LE ROY <stephane.leroy(a)st.com> Subject: RE: STM target - HAL version upgrade? Hi Tomasz, In our objectives, we have included the update of the STM HAL version. However, an exact date for its implementation has not been determined yet. Nevertheless, I anticipate that the timeline for its execution will not be significantly prolonged. Kind regards, Ahmad STM ST Restricted From: Tomasz Jastrzębski < <mailto:tdjastrzebski@wp.pl> tdjastrzebski(a)wp.pl> Sent: Tuesday, February 6, 2024 2:49 PM To: <mailto:tf-m@lists.trustedfirmware.org> tf-m(a)lists.trustedfirmware.org Cc: Ahmad EL JOUAID < <mailto:ahmad.eljouaid@st.com> ahmad.eljouaid(a)st.com>; Stephane LE ROY < <mailto:stephane.leroy@st.com> stephane.leroy(a)st.com> Subject: STM target - HAL version upgrade? Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

1 year, 8 months

1
0
0 0

STM target - HAL version upgrade?

by Tomasz Jastrzębski

Hi All, Are there currently any plans to update STM HAL version? HAL is a common component shared by all the STM boards. The currently used, relatively old version 1.0.0 does not support ST MCUs like STM32U5A9 and STM32U5G9 - the first one released a year ago. I need to decide where I should go ahead and do the update myself and since then probably maintain private TF-M version or maybe I should just wait because update is just on the way. Needless to say, an HAL update will probably take me way more effort than if it were done by someone who already knows the ropes. Kind regards, Tomasz Jastrzębski

1 year, 8 months

2
1
0 0

STM32U585 target - how to remove TF-M and bootloader?

by Tomasz Jastrzębski

Hi All, I think I am ready to try TF-M on B-U585I-IOT02A board. However, before doing so I want to make sure I know how to remove it when tests are done. Please advise. Tomasz

1 year, 9 months

2
1
0 0

Can primary and secondary images size change in opposite directions? (2)

by Tomasz Jastrzębski

Hi Anton, I think now I finally understand what I what to achieve with TF-M and it may not be achievable. I was hoping for the TF-M to be able to be able to manage both SPE and NSPE partition containing my LocalLoader using two slots of variable size placed in non-continuous memory. The PRIMARY LocalLoader slot has fixed start while the SECONDARY LocalLoader slot has fixed end, but byte order in secondary blocks can be reversed so bootloader always knows where to start - that is, at the end of flash memory where the header starts going backwards. My MainApp remains managed by LocalLoader using Secure FW services, not by TF-M/MCUboot directly. I am afraid that the above scenario is currently not achievable with TF-M because: - LocalLoader secondary slot must have a fixed start location - The memory area that Primary/Secondary slots occupy has to be continuous - Secondary slot reverse byte order is not supported - although probably fairly easy to implement. Is my understanding correct? Kind regards, Tomasz From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:32 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski

1 year, 9 months

2
2
0 0

Re: Can primary and secondary images size change in opposite directions?

by Tomasz Jastrzębski

Hi Anton I think what I really was uncertain about was whether sizes and locations of my LocalLoader "slots" have to be hardcoded somewhere so they cannot change, but it looks like it is not the case. As you pointed out, my LocalLoader app can just use TF-M crypto service to decrypt MainApp firmware update and then decompress it on its own. Ofc, out-of-the-box TF-M decryption-decompression (same time) service would be helpful, but there are no standard ones I am aware of and by no means lack of it is any show stopper. Kind regards, Tomasz Btw, I apologize for multiple posts, I thought those exceeding 80k would be just discarded. From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Tuesday, January 30, 2024 5:23 PM To: Tomasz Jastrzębski <tdjastrzebski(a)wp.pl>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] Can primary and secondary images size change in opposite directions? Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> > Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=s haring

1 year, 9 months

1
0
0 0

Re: Can primary and secondary images size change in opposite directions?

by Anton Komlev

Hi Tomasz, If I understand you correctly, then your scenario is fully implemented on NSPE side while TF-M is essentially responsible for SPE side only, allowing any functionality of NS application as long as it stays in the memory range allocated for NSPE. Does it help? I cut the image from the original mail to stay within the size limit (80K). Best regards, Anton From: Tomasz Jastrzębski via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 25, 2024 9:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Can primary and secondary images size change in opposite directions? Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. Local Loader update may result in the Main App update, but that is OK. Can primary and secondary LL images size change in opposite directions? Does TF-M support the described scenario? Image size flexibility is my goal. Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/17jrIfz0vE6OGJDWvXRn6TqNSh3mAX7e-/view?usp=… [cid:image002.png@01DA5399.4D502290]

1 year, 9 months

1
0
0 0

Getting basics working - how to? (ST B-U585I-IOT02A, STM32U5A9/U5G9 )

by Tomasz Jastrzębski

Hello All, I read the entire TF-M documentation, but I still do not quite understand how to get started with ST B-U585I-IOT02A, although my ultimate target is STM32U5A9/U5G9 MCU (4 MB of flash, 2.5/3.0 MB SRAM). 1. Based on Getting Started <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml> section I managed to compile TF-M solution, but I do not know how to properly flash the board using e.g. pyOCD or OpenOCD. How do I flash bl2.bin, tfm_(n)s.bin and tfm_(n)s_signed.bin? The only method I found was described here <https://trustedfirmware-m.readthedocs.io/en/latest/getting_started/index.ht ml#run-an521-regression-sample> and it relied on Arm Development Studio, a product which after 30-day evaluation must be purchased. 2. How do I update my NS application once the device is initially provisioned? I think this, although excellent TF-M documentation, is probably aimed at those who already are familiar with TF-M and could be supplemented with some "TF-M for dummies" section, better explaining basic concepts and the purpose all the TF-M services. Anyway, my goal is to implement as simple as it gets, yet secure firmware update. Firmware has to be signed and encrypted, ideally compressed as well. Firmware must be easily upgradable by non-technical users so USB stick with firmware file on it is the method of choice. What I envision is this process: 1. user inserts USB stick 2. device enters firmware update mode - probably performed by a separate, small and updatable "USB Loader" app, optionally using basic 1bit graphics, progress bar etc. - low flash & SRAM footprint. 3. "USB Loader" loads, verifies and decrypts new firmware using TF-M APIs and compresses it (if it was not compressed) when storing it in the internal SRAM. Compression may be required since internal SRAM on STM32U5A9/U5G9 (2.3/3.0 MB) is smaller than the flash size (4 MB). 4. Once the entire new firmware is loaded into internal SRAM, "USB Loader" decompresses it block-by-block and flashes flash, I suppose, again using TF-M APIs. Does the above process make sense? It is possible to implement it with TF-M? One potential challenge I can see is that, practically speaking, my "USB Loader" must use Microsoft FileX, USBX and, in consequence, ThreadX because probably only this way I can get USB-C and exFAT partitions support in a reasonable amount of time. TF-M docs do not list Microsoft ThreadX as a supported RTOS. Kind regards, Tomasz Jastrzębski

1 year, 9 months

3
7
0 0

STM32 target provisioning difficulties

by tomasz jastrzebski.net

After successful compilation I tried to provision B-U585I-IOT02A board following the steps described here: STM32U5 provisioning<https://trustedfirmware-m.readthedocs.io/en/latest/platform/stm/common/stm3…>. Process did not succeed due to the errors described below. What am I missing? postbuild.sh results in: Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./postbuild.sh ./postbuild.sh: line 22: /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts/preprocess.sh: No such file or directory preprocess bl2 file ./postbuild.sh: line 36: preprocess: command not found C:\Python312\python.exe: can't open file 'C:\\Temp\\tf-m\\trusted-firmware-m\\platform\\ext\\target\\stm\\common\\scripts\\scripts\\stm_tool.py': [Errno 2] No such file or directory postbuild.sh failed There are 3 versions of preprocess.sh script, it is compiler specific. TFM_UPDATE.sh has some syntax errors which reveal themselves under GitBash Thomas@AMDMINIATX MINGW64 /c/Temp/tf-m/trusted-firmware-m/platform/ext/target/stm/common/scripts (main) $ ./TFM_UPDATE.sh TFM UPDATE started ./TFM_UPDATE.sh: line 52: [: ==: unary operator expected ./TFM_UPDATE.sh: line 56: [: ==: unary operator expected ./TFM_UPDATE.sh: line 59: [: ==: unary operator expected These are easy to fix. Eg. if [ $encrypted == "0x1" ]; then -> if [ "$encrypted" == "0x1" ]; then It looks postbuild.sh and TFM_UPDATE.sh take two additional parameters which are not documented. regression.sh takes one undocumented parameter.

1 year, 9 months

5
5
0 0

Can primary and secondary images have clearly different sizes?

by tomasz jastrzebski.net

Hi All, I'm considering a scenario where users will be able to manually update device firmware from USB pen drive. For this reason, my Main App does not need a secondary copy kept in case update failed. If update fails, user can simply make another attempt a using different media or a different image. However, what needs to be protected against failed update is the Local Loader (LL) - updatable app reading files from pen drive, which updates the Main App. As new versions get developed and functionality is added (e.g. NTFS support), Local Loader (LL) may grow in size, hence the latest version may be clearly larger than the previous one. The same time I would like to be able to use all the remaining flash space for the Main App. All the above dictates the flash layout depictured below. LL1 size may be clearly different than LL2, Local Loader update may result in the Main App update, but that is OK. Does TF-M support the described scenario? Flexibility is the key. Can primary and secondary Local Loader (LL) images have clearly different sizes? Kind regards, Tomasz Jastrzębski https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=… [cid:image001.png@01DA4F08.95319C00]<https://drive.google.com/file/d/1n4Ihqk8S-04FlluvlveQflb5nYsXBluA/view?usp=…>

1 year, 9 months

2
3
0 0

Pre-encryption image compression (re-posting as a new topic)

by Tomasz Jastrzębski

Hello All, Does the current TF-M version support image compression before image is encrypted? Needless to say, compression after the image has been encrypted would not yield reasonable compression ratio. I am showing that *.bin files, even built with MinSizeRel option, zip-compress with minimum 50% compression ratio so probably this would make sense. Tested with STM32U5 target and GCC. "PSA Certified Firmware Update API <https://arm-software.github.io/psa-api/fwu/1.0/overview/architecture.html#m anifest> " document in sections 3.1 and 3.2 provides for image compression. Kind regards, Tomasz Jastrzębski

1 year, 9 months

2
2
0 0

SFN vs IPC partition with IPC backend

by Quach, Brian

If using IPC backend, how much performance and/or memory savings is there when using SFN vs IPC partition model? I saw FF-M v1.1 recommended SFN partition model but it was not clear to me why it was preferred. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 9 months

3
6
0 0

Getting started, ST B-U585I-IOT02A profile - compilation

by Tomasz Jastrzębski

Hi All, When I compile with GCC and Debug config (only Debug), process stops with these errors: [ 97%] Building C object bl2/CMakeFiles/bl2.dir/__/platform/ext/target/stm/common/hal/accelerator/stm .o [ 98%] Linking C executable ../bin/bl2.axf C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: ../bin/bl2.axf section `.ARM.exidx' will not fit in region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: address 0xc030fc4 of ../bin/bl2.axf section `.text' is not within region `FLASH' C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: section .BL2_NoHdp_Code LMA [0c02a000,0c02a5a7] overlaps section .text LMA [0c014000,0c030fc3] C:/Program Files (x86)/Arm GNU Toolchain arm-none-eabi/13.2 Rel1/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld.ex e: region `FLASH' overflowed by 28620 bytes Memory region Used Size Region Size %age Used FLASH_NVMCNT: 32 B 8 KB 0.39% FLASH: 118732 B 88 KB 131.76% FLASH_NOHDP: 1448 B 8 KB 17.68% FLASH_OTP: 756 B 4 KB 18.46% FLASH_NVM: 32 B 8 KB 0.39% RAM: 31624 B 63 KB 49.02% collect2.exe: error: ld returned 1 exit status make[5]: *** [bl2/CMakeFiles/bl2.dir/build.make:490: bin/bl2.axf] Error 1 make[4]: *** [CMakeFiles/Makefile2:1982: bl2/CMakeFiles/bl2.dir/all] Error 2 make[3]: *** [Makefile:136: all] Error 2 make[2]: *** [CMakeFiles/TF-M.dir/build.make:86: temp/src/TF-M-stamp/TF-M-build] Error 2 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Changing config to anything than Debug solves the issue, but along the way there are some warnings, of which these three seems to be particularly important: tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 65: warning: "MBEDTLS_ECP_MAX_BYTES" redefined tests_reg/build_spe/build-spe/lib/ext/mbedcrypto-src/include/mbedtls/ecp.h:3 66: warning: "MBEDTLS_ECP_MAX_PT_LEN" redefined trusted-firmware-m/bl2/ext/mcuboot/config/mcuboot-mbedtls-cfg.h:132:2: warning: #warning "Use legacy driver API for BL2" [-Wcpp] 132 | #warning "Use legacy driver API for BL2" When I try to compile with Clang compiler latest version 6.21, I immediately get this error: C:\Temp\tf-m\tf-m-tests\tests_reg>cmake --build build_spe -- install [ 12%] Creating directories for 'TF-M' [ 25%] No download step for 'TF-M' [ 37%] No update step for 'TF-M' [ 50%] No patch step for 'TF-M' [ 62%] Performing configure step for 'TF-M' loading initial cache file C:/Temp/tf-m/tf-m-tests/tests_reg/build_spe/temp/tmp/TF-M-cache-Debug.cmake -- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.43.0.windows.1") -- The C compiler identification is unknown -- The CXX compiler identification is unknown -- The ASM compiler identification is ARMClang -- Found assembler: C:/Program Files/ArmCompilerforEmbedded6.21/bin/armasm.exe CMake Error at toolchain_ARMCLANG.cmake:190 (message): Please select newer Arm compiler version starting from 6.13. Call Stack (most recent call first): CMakeLists.txt:50 (tfm_toolchain_reload_compiler) -- Configuring incomplete, errors occurred! make[2]: *** [CMakeFiles/TF-M.dir/build.make:92: temp/src/TF-M-stamp/TF-M-configure] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TF-M.dir/all] Error 2 make: *** [Makefile:124: all] Error 2 Please advise, Tomasz Jastrzębski

1 year, 9 months

2
2
0 0

Re: MemManage Fault during TF-M Secure Firmware Initialization

by Sari, Robert

Hi Jamie, thank you for the quick response! The culprit was indeed an MPU configuration that didn't comply with TF-M Isolation Level 2 requirements. Regards, Robert

1 year, 9 months

1
0
0 0

MemManage Fault during TF-M Secure Firmware Initialization

by robert.sari.ext＠siemens.com

Hello, I am currently having an issue during TF-M initialization where a MemManage fault is being triggered during secure FW initialization (most likely when the SPM is initialized). It appears to be an error during unstacking/returning from an exception as the MUNSTKERR bit of the MMFSR register is set. I receive the following exception context and exception frame when the error occurs: __________________________________________________________ FATAL ERROR: MemManage fault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFFD Exception came from secure FW in thread mode. xPSR: 0x20000004 MSP: 0x20000BF8 PSP: 0x20002518 MSP_NS: 0x20042DF8 PSP_NS: 0xFFFFFFFC Exception frame at: 0x20002518 (Note that the exception frame may be corrupted for this type of error.) R0: 0x00000000 R1: 0x00000000 R2: 0x00000000 R3: 0x00000000 R12: 0x00000000 LR: 0xFFFFFFFE PC: 0x000358D1 xPSR: 0x01000000 CFSR: 0x00000008 BFSR: 0x00000000 BFAR: Not Valid MMFSR: 0x00000008 MMFAR: Not Valid UFSR: 0x00000000 HFSR: 0x00000000 SFSR: 0x00000000 SFAR: Not Valid __________________________________________________________ Other Information: - I am running Nordic Semiconductor's "tfm_psa_template" sample: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrf/samples/tfm/… - The Secure MPU is enabled (only the background region) before TF-M initialization begins - Board: nRF5340dk - TF-M Version: v1.8.0 - TF-M Isolation Level: 2 My questions are: - What part of the TF-M FW could be the cause of this MemManage fault? - Is there any way to solve this issue (such as a different TF-M configuration) so that TF-M will initialize properly? Regards, Robert Sari

1 year, 9 months

2
1
1 0

Memory Footprint Table generation

by Ruchika Gupta

Hi, With every TFM release, I see that there is a memory footprint table<https://trustedfirmware-m.readthedocs.io/en/latest/releases/2.0.0.html#refe…> which is made available for the AN521 platform. Are there any scripts available to run on the map file/other binaries to generate this table ? I would like to use the same for our platform and do some analysis. Further question- Why is there a tie up between the large profile with TFM isolation level 3 ? Is it a certification requirement ? Regards, Ruchika

1 year, 9 months

3
2
0 0

Re: Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hi Antonio, Thank you for your information, it is very helpful. Best regards Tao Li (William Lee) Software Engineer @ Garmin Mobile: +8618628138760 From: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Reply-To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Date: Monday, January 1, 2024 at 06:58 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe. Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs…<https://urldefense.com/v3/__https:/developer.nordicsemi.com/nRF_Connect_SDK…> A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM…<https://urldefense.com/v3/__https:/www.psacertified.org/app/uploads/2021/12…> Sent from Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!EJc4YC3iFmQ!X1Zeo-qnf…> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr…<https://urldefense.com/v3/__https:/www.nxp.com/products/processors-and-micr…> Thank you! Best regards William Lee

1 year, 10 months

1
0
0 0

Re: Are MCUs without internal flash not supported by TF-M?

by Antonio De Angelis

Hi Torsten, you can have a look at the design document for ITS which describes encryption in ITS for a generic introduction: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/tfm/design_docs… A platform supports ITS_ENCRYPTION=ON if it provides an implementation of the HAL functions as follows: tfm_hal_its_aead_* For the exact list of Nordic platforms that support this option I suggest to have a look directly in the Nordic Connect SDK. Probably any platform based on the 5340 would be able to support this option, but there might be other platforms as well which you would be able to use through the SDK itself. Hope this helps. Thanks, Antonio ________________________________ From: Labs, Torsten via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Saturday, December 30, 2023 14:51 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi antonio, Thanks for those interesting news. Do you know on which Nordic platform supports encrypted ITS with TFM? Regards Torsten ________________________________ Von: Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Gesendet: Saturday, December 30, 2023 9:31:10 AM An: Lee, William <William.Lee(a)garmin.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Betreff: [TF-M] Re: Are MCUs without internal flash not supported by TF-M? Hi William, The requirement on the storage is for it to be isolated, either physically or cryptographically, as you can read from the PSA security model [1]. TF-M initially supported only the isolated model in ITS (i.e. for internal flashes) but more recently it was added support for encrypted ITS, which I believe it can be used on one of the Nordic platforms already. Hope this helps. Thanks, Antonio [1] Platform Security Model - PSA Certified https://www.psacertified.org/app/uploads/2021/12/JSADEN014_PSA_Certified_SM… Sent from Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Lee, William via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, December 29, 2023 5:53:50 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Are MCUs without internal flash not supported by TF-M? Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

1 year, 10 months

1
0
0 0

Are MCUs without internal flash not supported by TF-M?

by Lee, William

Hello everyone, Happy New Year! Are MCUs without internal flash not supported by TF-M? From TF-M’s documents, I saw ITS(Internal Trusted Storage) is a PSA-ROT secure service and requires store data in internal flash. Does that mean TF-M not support hardware platforms that do not have internal flash? For example, RT500 does not have internal flash: https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontr… Thank you! Best regards William Lee

1 year, 10 months

3
2
0 0

Minor updates to the tf.org project maintenance

by Sandrine Bailleux

Hello TF-A and TF-M communities, I've done 2 minor updates to the generic tf.org project maintenance process, which TF-A and TF-M both use. Please see the pull request here: https://github.com/TrustedFirmware/tf_docs/pull/1 Please provide your feedback on the pull request, if any. Happy end-of-year celebrations to all! Best regards, Sandrine

1 year, 10 months

1
0
0 0

Arm v8 FPU questions

by Bohdan.Hunko＠infineon.com

Hi all, I have been working with FPU lately and I have a few questions regarding this topic: Looks like there are 4 use cases of FPU usage: FPU is used in Use case number SPE NSPE 1 - - 2 - + 3 + - 4 + + From https://tf-m-user-guide.trustedfirmware.org/integration_guide/tfm_fpu_suppo… my understanding is following: 1. If SPE and NSPE both does not use SPU (use case 1) then they both must be compiler with fp=soft? 2. consistent FP ABI types between SPE and NSPE must be used. So even if only one of SPE or NSPE (use cases 2 and 3) does not use FPU they both still must be compiler with fp=hard Also if both SPE and NSPE use PFU then they both must be compiler with fp=hard 3. Even if FPU is not used by NSPE, NSPE still MUST enable CP10 an CP11? - Is this correct? Is it possible to enable FPU for SPE but don't enable CP10 and CP11 in NSPE? So basically if either SPE or NSPE or both of them need to use FPU then both of them need to enable CP10 and CP11 and be compiled with fp=hard Is my understanding correct? Inline comments are welcome. 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>

1 year, 10 months

2
1
0 0

How to disable all interrupts on ARM V8?

by Bohdan.Hunko＠infineon.com

Hi all, From what I have seen, looks like __disable_irq() only disables non-secure interrupts when called from NSPE on ARM v8 arch. Am I correct? If so then how can I disable all interrupts (including secure interrupts) from NSPE? - We need this for critical section and other critical code. 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>

1 year, 10 months

2
1
0 0

Problems with integrating TF-M with RIOT OS

by Boeckmann, Lena

Hi everyone! I am currently integrating TF-M with an IoT OS (RIOT OS) and I have a few problems. I managed to build and link a secure TF-M binary and a non-secure RIOT binary and I can run some application code (print "hello world", turn LEDs on and off, etc) on the nRF9160dk. I can also use the crypto API and call psa_crypto_init. Now I have tried a few things and each of them leads to different problems, some of which I will describe in this mail hoping that someone can help me with this. I have done some debugging and have some ideas on what could be wrong, but I don't really understand how to fix the issues and don't really know how to proceed with either of them. Formatted Prints Somehow formatted prints are ignored. Calls to printf without formatting default to the stdio puts implementation and are printed without issues. Calls to printf with formatting use the implementation in tfm_sp_log_raw.c and are just ignored. They crashed at first, but I could fix that (RIOT has different implementations of the SVC ISR and I used the wrong one). Now they don't crash anymore, but are also not printed (no error output, application keeps running). Since this function is part of the secure firmware, my guess is that there's a problem with it being called from the NS world. But that should result in a SecureFault, shouldn't it? Does anyone have an idea what the issue could be? Secure memset called from NS image When calling psa_generate_key, the first step is a struct initialization: struct tfm_crypto_pack_iovec iov = { .function_id = TFM_CRYPTO_GENERATE_KEY_SID, }; This runs into a SecureFault. It turns out that during struct initialization, memset is called to zeroize the structure. This uses the memset implemented in secure_fw/shared/crt_memset.c and accesses secure RAM (between addresses 0x20015000 and 0x20016000). I found a workaround by moving the start address of NS RAM from 0x20016000 to 0x20020000. Memset now still accesses RAM before NS RAM, but does not run into a SecureFault anymore. This works for now, but I would like to find an actual fix for this. This only occurs when building with RIOT. When building the TF-M NS image and running crypto tests, memset accesses NS RAM, though I don't know if the same implementation is used. Unfortunately I don't get any debug symbols there. Could it be that a different memset implementation should be linked? Can I change it somehow? Can someone tell me which one is linked in the TF-M NS image? Crypto partition is NULL When using the workaround described above, calling psa_generate_key runs into tfm_core_panic. The stack trace here is: psa_call (tfm_psa_call.c) tfm_psa_call_pack (backend_sfn.c) tfm_spm_client_psa_call (psa_call_api.c) tfm_spm_is_ns_caller (spm_ipc.c) The problem is in tfm_spm_is_ns_caller, where struct partition_t *partition = GET_CURRENT_COMPONENT(); gets a NULL pointer. So somehow there is no crypto partition available. Of course I have enabled the crypto partition in config_base.cmake, as well as protected storage and internal trusted storage. I checked with a debugger and found out that during start up, multiple partitions are initialized and added to the global component list (stored in backend_sfn.c). Can I somehow check what types of partitions are initialized? Did anyone have a similar issue before or has any idea why the partition could be missing? Did I miss any extra steps I need to take? I know these are pretty much unrelated issues, but they are persistent and I am at a loss at how to fix them. I will take any hints and ideas, including pointers to where I can find relevant information in the docs (those have not been very helpful in these cases, but maybe I've overlooked something). Best regards, Lena

1 year, 10 months

2
2
0 0

Weird behavior of Clang linker

by Bohdan.Hunko＠infineon.com

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>

1 year, 10 months

3
3
0 0

Re: Attestation token new spec

by Tamas Ban

Hi, Sorry 2nd link was broken. Here is the working version: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab… Tamas Ban From: Andersson, Joakim <Joakim.Andersson(a)nordicsemi.no> Sent: 2022. május 9., hétfő 12:14 To: Tamas Ban <Tamas.Ban(a)arm.com> Subject: RE: Attestation token new spec Is te second link broken? I get a 404 error code. -Joakim From: Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: mandag 9. mai 2022 11:31 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Attestation token new spec Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack…> This spec is still evolving and there is a newer version which changes the key values of the claims in the token: https://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html#tab…<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.…> This can cause combability issues between token issuer (device) and token verifier (some remote verification service). This is an ABI change between token issuer and consumer. The breaking effect would be manifest in unaccepted IAT tokens by the verifier. On-device side I see these options to make the transition: - A build-time option could be introduced which determines which range of key numbers to use. The default value would be the new range. To not let new users pick up the old values accidentally. Existing users can notice the incompatibility issue during the integration test and adjust their build command accordingly. However, the old range would be announced as deprecated in the next TF-M release, then will be removed in the next release after. - Immediate switch over to the new range, without supporting the old range anymore. On the verification service side, an SW update can handle the transition and might be accepting both ranges for a while. I assume the verification service can be updated more easily than remote devices therefore better to handle the compatibility issue there. - Keeping the support for both ranges for the long term and letting users choose by build time. Please share your thoughts on: - Are you aware that the attestation service is used in deployed devices where this transition can cause incompatibility? - From the above list which option would you vote to support the transition? Best regards, Tamas Ban

1 year, 10 months

3
4
0 0

FIH volatile structure and stack usage

by Roman.Mazurak＠infineon.com

Hi all, I found that using FIH medium/high profile with gcc generates code that uses stack extensively. It happens because fih_int structure is marked as volatile. Is there any reason why structure itself is marked as volatile? Why it's not enough to make val and msk volatile members of fih_int structure? Best regards, Roman.

1 year, 10 months

2
4
0 0

Redundant checks in FWU code

by Bohdan.Hunko＠infineon.com

Hi all, In config/check_config.cmake there is a following code: tfm_invalid_config((MCUBOOT_UPGRADE_STRATEGY STREQUAL " DIRECT_XIP " OR MCUBOOT_UPGRADE_STRATEGY STREQUAL "RAM_LOAD") AND TFM_PARTITION_FIRMWARE_UPDATE) So looks like FWU is not supported when DIRECT_XIP or RAM_LOAD upgrade strategies are used. But then in FWU code I see a lot of checks for DIRECT_XIP or RAM_LOAD, for example in fwu_bootloader_get_image_info: #if !defined(MCUBOOT_DIRECT_XIP) && !defined(MCUBOOT_RAM_LOAD) && \ !defined(MCUBOOT_OVERWRITE_ONLY) What is the point of these checks if it is impossible to compile FWU code with DIRECT_XIP Because of check in config/check_config.cmake? 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>

1 year, 10 months

3
5
0 0

[RFC] Bump minimum CMake version required

by David Hu

Hi all, The current minimum CMake version specified in TF-M is 3.15. It is quite out-of-date. I’d like to propose to increase minimum CMake version to 3.21. CMake 3.21 can bring in some benefits, compared to CMake 3.15 * NEW behavior of several CMake policies, such as CMP0123 for Armclang. * After build split, TF-M secure build installs several build scripts. When NS build includes those build scripts, `CMAKE_CURRENT_FUNCTION_LIST_FILE/DIR` can make it easier to handle source code paths. CMake 3.21 was released 2 years ago. It should be stable enough now. May I know if you have any feedback or different opinions? Thank you. Best regards, Hu Ziji

1 year, 10 months

2
4
0 0

Reduce dependency of NS Mailbox structure on non-secure configurations

by Roman.Mazurak＠infineon.com

Hi all, I faced the problem that mailbox configuration of secure image differs from one provided for non-secure. It's because I'm using a split-build but a little bit different that is prepared for v2.0. I think we can minimize dependencies and unexpected impacts between different images when common data structures will have less customization. Currently we have three options that can change mailbox structures: 1. NUM_MAILBOX_QUEUE_SLOT - number of mailbox slots 2. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD - defines which NS client implementation is selected. 3. TFM_MULTI_CORE_TEST - specify whether NS multi-core test suite is built. There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive. Because it's important that secure side is not using slots that are not used by non-secure side. It can be possible to use NS bare metal client even if mailbox queue size is more than one, it's just the waste of resources in such case. But it can bring a benefit that it's possible to build secure image with default settings (aka 4 mailbox slots) and there is no need to rebuild it if there will be decision to switch from RTOS to bare metal environment which can be useful for some end-user use cases. More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it's just important to validate that number of slots doesn't not exceed maximum supported by design. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it's important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem: 1. Use union to allocate space for both of them and let decide NS client implementation which on to use. Something like this: struct mailbox_reply_t { union { //#ifdef TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD uint8_t *woken_flag; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#else bool is_woken; /* Indicate that owner task has been * or should be woken up, after the * reply is received. */ //#endif }; }; 1. Redesign mailbox by separating data that are used by NS client from data that are shared between cores. So, it will be much easier to update non-secure client without touching secure image. It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only, so there will be no need to allocate this data in shared structure and there will not be the case when location of is_full field of ns_mailbox_queue_t accessed by both cores have different location if TFM_MULTI_CORE_TEST configuration is not applied the same way for both secure and non-secure images. Regards, Roman.

1 year, 10 months

3
7
0 0

FPU flags for mbedTLS targets

by Quach, Brian

Hi, /secure_fw/partitions/crypto/CMakeLists.txt is missing passing compiler flags to mbedTLS targets which would be needed for correct FPU flags. I believe the highlighted code would be the fix: target_compile_options(${MBEDTLS_TARGET_PREFIX}mbedcrypto PRIVATE ${COMPILER_CP_FLAG} $<$<C_COMPILER_ID:GNU>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:GNU>:-Wno-unused-parameter> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-const-variable> $<$<C_COMPILER_ID:ARMClang>:-Wno-unused-parameter> ) target_compile_options(${MBEDTLS_TARGET_PREFIX}p256m PRIVATE ${COMPILER_CP_FLAG} ) Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 10 months

2
5
0 0

compile error when PS_ENCRYPTION=OFF

by Quach, Brian

Hi, if I set PS_ENCRYPTION=OFF set(PS_ENCRYPTION OFF CACHE BOOL "Enable encryption for Protected Storage partition") I see this compile error: In file included from /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/tfm_internal_trusted_storage.c:32: /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:31: error: 'PS_TAG_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:48:50: error: 'PS_IV_LEN_BYTES' undeclared here (not in a function) 48 | #define PS_TAG_IV_LEN_MAX ((PS_TAG_LEN_BYTES > PS_IV_LEN_BYTES) ? \ | ^~~~~~~~~~~~~~~ /home/brian/gits/spe/source/third_party/tfm/secure_fw/partitions/internal_trusted_storage/../protected_storage/ps_object_defs.h:60:20: note: in expansion of macro 'PS_TAG_IV_LEN_MAX' 60 | uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; | ^~~~~~~~~~~~~~~~~ make[7]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:90: secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/tfm_internal_trusted_storage.o] Error 1 I think the correct fix is to add the following highlighted code to ps_object_defs.h. Patch is attached. /*! * \struct ps_object_t * * \brief The object to be written to the file system below. Made up of the * object header and the object data. */ struct ps_object_t { struct ps_obj_header_t header; /*!< Object header */ uint8_t data[PS_MAX_OBJECT_DATA_SIZE]; /*!< Object data */ #ifdef PS_ENCRYPTION uint8_t tag_iv[PS_TAG_IV_LEN_MAX]; #endif }; Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 10 months

2
1
0 0

psa_call with NULL outvec causes a NULL pointer dereference

by Quach, Brian

Hi, Is it possible to call psa_call() with NULL outvecs with TF-M v2.0? I am using IPC model. This worked for me with TF-M v1.8 but now I see get a NULL pointer dereference with TF-M v2.0 when psa_reply() is called. Specifically, it happens inside update_caller_outvec_len(). It seems msg.out_size[i] is non-zero (due to a previous psa_call which had 3 outvecs). handle->caller_outvec[i].len causes a NULL pointer deference. void update_caller_outvec_len(struct connection_t *handle) { uint32_t i; for (i = 0; i < PSA_MAX_IOVEC; i++) { if (handle->msg.out_size[i] == 0) { continue; } SPM_ASSERT(handle->caller_outvec[i].base == handle->outvec_base[i]); handle->caller_outvec[i].len = handle->outvec_written[i]; } } spm_associate_call_params() does not clear msg.out_size[] so the previous contents remain. One potential fix is to add the highlighted code below to clear out_size[]. [cid:image001.png@01DA27A5.8860E6F0] Regards, Brian Quach SimpleLink MCU Texas Instruments Inc. 12500 TI Blvd, MS F-4000 Dallas, TX 75243 214-479-4076

1 year, 10 months

2
3
0 0

Partition log write UART without validation of permissions.

by Roman.Mazurak＠infineon.com

Hi all, I noticed that partition log subsystem uses stdio_output_string through following chain of calls tfm_hal_output_sp_log => SVC TFM_SVC_OUTPUT_UNPRIV_STRING => tfm_hal_output_spm_log => stdio_output_string. SVC handler doesn't validate arguments, so it's allows APP RoT partitions to access PSA RoT memory via partition log subsystem. It seems that tfm_hal_memory_check must be called on SVC handler to validate permissions. Best Regards, Roman.

1 year, 11 months

2
1
0 0

preload.cmake

by Quach, Brian

Hi, I'm seeing references in the documentation for preload.cmake and several files with that name in TF-M v2.0.0. But looking at the code it seems like preload.cmake was replaced with cpuarch.cmake. Am I missing something? Where should be put fixed platform-specific definitions which are not related to CPU architecture? Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 11 months

2
3
0 0

Redundant check on FWU_DEVICE_CONFIG_FILE

by Bohdan.Hunko＠infineon.com

Hi all It seems to me like following check # FWU_DEVICE_CONFIG_FILE exists and is a file if(NOT EXISTS ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} does not exist.") elseif(IS_DIRECTORY ${FWU_DEVICE_CONFIG_FILE}) message(FATAL_ERROR "FWU_DEVICE_CONFIG_FILE:${FWU_DEVICE_CONFIG_FILE} is a folder while a file is expected.") endif() in secure_fw/partitions/firmware_update/CMakeLists.txt is redundant as FWU_DEVICE_CONFIG_FILE may be generated, thus not present when cmake performs EXISTS check (note that by default FWU_DEVICE_CONFIG_FILE is generated so I dont see point in limiting user from using generated file) So i propose to remove this check. 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>

1 year, 11 months

2
6
0 0

TF-M release v2.0.0 announcement

by Anton Komlev

Hello, I am happy to announce the new release of TF-M v2.0.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv2.0…>. The major version update indicates the important changes in the way TF-M builds. New major features are: * TF-M secure build process and non-secure build process are split. * Refer to TF-M Build Instruction to build SPE image. * Refer to Building Tests to build non-secure tests. * Update new Mailbox agent API. * Decouple the specific application Mailbox from SPM, make it an application in Secure Partition. * Unify the interfaces between partitions and SPM, and reduces the interaction interface between them. * Multi-core support in the Secure Function (SFN) model. * Optimize SPM critical section implementation to reduce time cost in isolation level 2&3. * Use local variables for connection handles instead of dynamic allocation. * P256-M component is enabled on the TF-M side in profile medium. * MCUboot upgrade to v2.0.0. * Mbed TLS upgrade to v3.5.0. * TF-M PSA client API performance profiling is tracked in SQUAD and the profiling tool is updated. * TF-M integrates Read the Docs. Please check the release notes<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/25143/12/doc…> 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

1 year, 11 months

2
1
0 0

Deprecate Laird Connectivity platform

by Andersson, Joakim

The Laird Connectivity platform board BL5340 DVK no longer compiles in the main branch of TF-M after the split build feature was merged. The BL5340 DVK is a module that contains the nRF5340 SoC, because of this the platform is re-using the Nordic platform support files. This cross-reference is causing us, the maintainers of Nordic a lot of problems as making changes to the Nordic platform code can break the Laird Connectivity platform. We don't have this board either to run any tests and confirm any changes. Laird Connectivity has not contributed to the platform support for more than a year. Nordics strategy for maintaining support for TF-M is to have the base DK supported in TF-M for testing purposes, and then provide support for all other boards in our SDK through our board support configuration system. Removing the platform from TF-M will still mean that the BL5340 DVK board is supported in the nRF Connect SDK. To support the board in the Zephyr Project the following PR is needed: https://github.com/zephyrproject-rtos/zephyr/pull/65823 Joakim Andersson Nordic Semiconductor

1 year, 11 months

1
0
0 0

How can use Mailbox in TF-M on Dual-core System ?

by 진국 박

hello. I have ported corestone1000 plaform to tfm and am trying to use mhu to send and receive messages between secure enclave (SPE)core and host core(NSPE). (I want to use it for future encryption requests). Looking at the rss platform and corstone-1000 tfm code, the function for initializing and registering the mhu seems to be tfm_inter_core_comm_init. But I can't find the part that calls tfm_inter_core_comm_init. Can anyone tell me the procedure and a simple example of sending and receiving messages using MHU in a TFM environment? I've been looking through the TFM documentation, but I can't find it yet. Below is the tfm_inter_core_comm_init function to register the rpc of the spe in rss. I was wondering where the function below is called and used. int32_t tfm_inter_core_comm_init(void) { int int32_t ret; /* Register RPC callbacks */ ret = tfm_rpc_register_ops(&rpc_ops); if (ret != TFM_RPC_SUCCESS) { return ret; } /* Platform specific initialization */ ret = tfm_multi_core_hal_init(); if (ret != TFM_PLAT_ERR_SUCCESS) { tfm_rpc_unregister_ops(); return ret; } } return TFM_RPC_SUCCESS; } You are a newbie to TFM and are looking for help.

1 year, 11 months

3
3
0 0

Flashing problems on B-U585I-IOT02A

by João Bento

Hello, I have recently trying to flash the B-U585I-IOT02A board by running the 3 scripts generated in the build folder, as I usually do with the STM32L552 board. However, I encountered some unexpected errors as I noticed that the secure and non-secure images were being written to external flash address spaces. I quickly noticed that this was happening because the "flash_layout.h" file defines the variable "EXTERNAL_FLASH". Additionally, the "image_macros_to_preprocess_bl2.c" set the image as encrypted by default with "RE_IMAGE_ENCRYPTED= 0X01", causing the "TFM_UPDATE.sh" script to write to the secondary slots. I found it quite strange because tf-m presented an off-the-shelf solution for the other board while for this board it assumes the use of an external flash. Nevertheless, I tried to work around these limitations by commenting the EXTERNAL_FLASH variable and assigning the "RE_IMAGE_ENCRYPTED= 0X00" similarly to the stm32l552. This led to the images being written to the primary slots defined in the flash layout, however, in runtime I encountered an error that states "Unable to find bootable image". Therefore, my question is: Do I need to make further adjustments, or is it possible that there's a configuration issue that is not compatible with the board? Best regards, João Bento

1 year, 11 months

2
4
0 0

Start of TF-M v2.0.0 release

by Anton Komlev

Hello, The branch release/2.0.x<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/log/?h=release/…> has been created indicating the start of the release process and features freeze. RC1 tag will follow after a successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch as described in TF-M Release Process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Thanks, Anton

1 year, 11 months

1
2
0 0

PSA_FRAMEWORK_HAS_MM_IOVEC

by Quach, Brian

Hi, I saw that PSA_FRAMEWORK_HAS_MM_IOVEC is not permitted for Isolation level 2-3 and transient copies of the input and output data into a 5KB scratch buffer are always made when making a PSA call. This makes sense as FF-Mv1.1 states: “In a system using isolation level 3, a Secure Partitions is not permitted to access another Secure Partition’s Private data. MM-IOVEC can provide a mechanism for one Secure Partition to access the other’s Private data.” But I think the requirements for isolation level 3 could be fulfilled by: If SP detects a Secure caller, it could make a transient copy of I/O data. If SP detects a Non-Secure caller, it could use MMIOVECs or a similar method to access NS memory directly to avoid overhead and limitations of copying the I/O data. Is this logical/ correct? With this approach, an attacker may tamper NS input data while the RoT service is processing those data but rules of isolation level 3 are maintained. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

1 year, 11 months

2
3
0 0

Various issues in successfully using GDB to debug secure apps on Musca S1 connected over USB DAPLink to a Linux host

by Arun D

Now sure where exactly this belongs, but I already posted question abut the Musca S1 earlier, and this seems relevant. ARM support essentially seem to tell me that they cannot support GDB and they are not certain of DAPLink, and recommend ULINKPLUS debugger with ARM IDE. So wanted to get a sense from anyone who has attempted to use this. In the following I describe the steps to obtain a base line, then provide description in what way GDB / DAPLink seems to misbehave. To get a base line: ~~~~~~~~~~~~~ - I build 'samples/hello_world' app using Zephyr 'v3.4.0'. Copy the 'build/zephyr/zephyr.hex' file to '/media/user/MUSCA_S1' directory when the board is USB. Connect a terminal emulator to the UART exposed by USB DAPLink, e.g. 'picocom -b 115200 -y n /dev/ttyACM0'. I can see on the console the followinbg *** Booting Zephyr OS build zephyr-v3.4.0 *** Hello World! musca_s1 If I press the reset button, the app restarts as well. This is as expected. I note that this is entirely running as in secure mode, that it does not use TF-M. - Next I start 'pyocd-gdbserver'. Then start a GDB session using the 'zephyr.elf' file, 'target remote localhost:3333' to connect it to the gdbserver. It connects ok. So I put a breakpoint at "main", do a 'monitor reset halt', and then continue. The breakpoint at 'main' is hit, I can obtain the backtrace to see it is correct as expected. So my setup seems good. Next I attempt to test a non-secure app with TF-M. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Build the app using Zephyr build env 'west build -b v2m_musca_s1_ns samples/tfm_integration/tfm_psa_test/ -DCONFIG_TFM_PSA_TEST_CRYPTO=y'. Copy 'build/zephyr/tfm_merged.hex' to '/media/user/MUSCA_S1'. Connect a terminal emulator, picocom, to the console, and hit the PBON (power on) button. I see the following output as expected on the console: Musca-S1 Dual Firmware Version 1.9 [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! Booting TF-M 79a6115d3 [INF][Crypto] Initialising HW accelerator... complete. *** Booting Zephyr OS build zephyr-v3.4.0 *** ***** PSA Architecture Test Suite - Version 1.4 ***** Running.. Crypto Suite ****************************************** TEST: 201 | DESCRIPTION: Testing crypto key management APIs | UT: psa_crypto_init [Info] Executing tests from non-secure This is as expected. However, if I press the reset button the board does not appear to reset - this is unexpected. Has anyone seen a different behavior? Is the specific board that I have is misbehaving? - Now I start PyOCD GDB server, start GDB and successfully connect it to the GDB server. The target is halted where it was executing, e.g. Remote debugging using localhost:3333 CC_HalWaitInterruptRND (data=data@entry=1024) at /home/zephyr/zephyrproject/modules/tee/tf-m/trusted-firmware-m/lib/ext/cryptocell-312-runtime/host/src/hal/cc3x/cc_hal.c:107 107 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR)); (gdb) This is as expected. - Next I put a breakpoint at 'sprt_main', then issue a 'monitor reset halt', then issue a 'continue', The breakpoint is is NOT hit. I see a blue LED blink at perhaps 4 times per second. This is unexpected. Has anyone seen this behave correctly? Do I have a board that is misbehaving?

1 year, 11 months

4
10
2 0

Building TF-M for ARM reference SoC/boards MPS2/MPS3 and Musca S1

by capablegh＠gmail.com

Hello. The ARM MPS2/MPS3 have Cortex M33 two processor configuration. I am building TF-M under the Zephyr OS setup. From the build it appears that the secure (TF-M) and non-secure (Zephyr OS and app) are bound and executed on separate CPUs. Assuming that two CPUs are used, in the build, is there a way to force using same one CPU for TF-M and Zephyr/app, while disabling the second CPU? Thanks.

1 year, 11 months

5
12
1 0

Increasing the flash partition for the Secure Firmware in TF-M for MPS2-AN521 board emulated using Qemu

by Gowri Ramshankar

Problem: ARoT app is too large, that the image build fails. Error: /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: bin/tfm_s.axf section `.ER_UNPRIV_CODE' will not fit in region `FLASH' /home/gramshan/zephyr-sdk-0.16.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 114956 bytes Memory region Used Size Region Size %age Used FLASH: 572684 B 447 KB 125.11% RAM: 54556 B 1 MB 5.20% To overcome this issue, I changed the flash_layout header file (https://github.com/zephyrproject-rtos/trusted-firmware-m/blob/master/platfo…) such that the secure side size is (FLASH_S_PARTITION_SIZE) 700+KB from the 512KB default for the MPS2 AN521 app, and correspondingly update the non-secure side FLASH_NS_PARTITION_SIZEto be 300KB. This builds the tfm_merged.hex file, But fails it to boot the app. So, I do not use your ARoT, but just built as non-secure app - the 'hello_world' Zephyr app that prints a one line hello_world on the console, but using the modified partition layout. This too fails to boot, in that the "hello world" is not printed. I debugged this to find that it is BL2 that is failing. I see that the Panic occurs during the image swapping operation, this is because the image to be filled in the primary slot is identified as invalid and the secure boot stops. The TF-M thinks some firmware upgrade is happening, the integrity check fails and panics, thus inducing a Fault Injection Hardening defense. Now I am stuck with this issue and I do not know how to proceed further, any help on how to change the flash partition sizes in a clean manner would be appreciated.

1 year, 11 months

3
5
0 0

Scheduling bug

by Bohdan.Hunko＠infineon.com

Hi There seem to be scheduling bug we have found in SPM. This bug is related to handling of interrupts that arrives during SVC call and assert signed for partition. Steps to reproduce: 1. Call psa_wait() from partition (e.g. mailbox partition) 2. During execution of SVC handler generate Interrupt that asserts signal of that partition (e.g. mailbox partition signal ) (adding long delay in SVC handler or adding breakpoint in SVC handler helps to easier reproduce this ) 3. Following sequence happens: * Mailbox IRQ has lower priority than SVC thus SVC is not preempted. * SVC sees that mailbox partition is blocked (as it is waiting for signal and no signals are pending) * SVC triggers pendSV i. Mailbox IRQ and pendSV are both pending * Mailbox IRQ has higher priority than pendSV thus Mailbox IRQ is executed * Mailbox IRQ calls spm_handle_interrupt i. Signal is asserted thus spm_handle_interrupt in thrd_next calls query_state_cb which returns THRD_STATE_RET_VAL_AVAIL and thus tfm_arch_set_context_ret_code is called ii. tfm_arch_set_context_ret_code sets return code using OLD value of partition PSP (as it was never updated, as it is updated in PendSV) * Mailbox IRQ return, pendsv is started and it runs mailbox partition i. Mailbox partition has 0 as signal because return value was written to wrong location is stack Patch I have attached to the mail solves this problem for us BUT it seems more like a workaround than a proper fix( Anyways it would be nice to have this problem review by SPM experts and have proper fix (maybe we have other places with same problem...) 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>

1 year, 11 months

2
2
0 0

Merging build split feature branch back to main branch

by David Hu

Hi, I’d like to give you a heads-up that build split feature branch will be merged back to main branch very soon this week. Trusted-firmware-m build split branch: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/?h=feature… Tf-m-tests build split branch: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/?h=feature-build-s… Build split feature improves how NS side integrate with TF-M SPE and therefore build commands are changed for building regression tests and PSA arch tests. Could you please refer to https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/23898 for updated commands/configuration to integrate NS side and port platforms after build split? If anything is broken after build split, please let us know. It would be also appreciated if you could contribute to build split. 😊 Any feedback or comment is welcome. Best regards, Hu Ziji

1 year, 11 months

1
1
0 0

How is Secure Enclave configured?

by Sunguk Bin

I have a few questions regarding RSS and Secure Enclave to see what's required and considered for SoC design to leverage RSS and why we nee to use RSS & TF-M 1. What is the difference between RSS and Secure Enclave? - Is RSS the same as Secure Enclave? - Or is it referring to any subsystem providing runtime crypto service regardless of whether it's a Secure Enclave or not? Question below is assuming RSS is a Secure Enclave...... 2. What enables TF-M to operate as a Secure Enclave? - To operate as a Secure Enclave, HW support is mandatory? a) If so, we must use a Secure Enclave IP such as cryptoisland(CI-300P-C)? b) Or can we construct a Secure Enclave with some other IPs(LCM, KMU, CryptoCell) metioned RSS doc? (by using TF-M without secure enclave IP) It feels vague whether this can be called a Secure Enclave... https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_manage… - If HW support is not mandatory, I wonder how TF-M can operate as a Secure Enclave. - The article below seems to say that TF-M can provide Secure Enclave functionality without HW support. or I may misunderstand. https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/tfm/technical_re…

2 years

2
5
0 0

Non-secure client id management

by Chris.Brand＠infineon.com

Hi, Reading through https://tf-m-user-guide.trustedfirmware.org/integration_guide/non-secure_cl… I'm wondering why so much of the work is done in the secure world. Ultimately, the secure world relies on the non-secure world to tell it the client_id, directly or indirectly. Is there a good reason for the NCSE part to reside in the secure world, rather than the non-secure? Particularly as the document states that the non-secure RTOS may have a built-in "Secure Context Manager", there may well be redundancy between that and NCSE that could be eliminated if the NCSE was in the NSPE. And the less code there is in the secure world, the less scope for vulnerabilities. If client_ids themselves were passed from the NS to the S world, it would probably be very easy to use that same interface on the NS core in a dual core system, too. Chris

2 years

2
1
0 0

Bool cast is wrong in Corestone cmake file

by Bohdan.Hunko＠infineon.com

Hi, Seems like following code $<$<BOOL:TFM_PARTITION_PLATFORM>:${CMAKE_CURRENT_SOURCE_DIR}/services/src/tfm_platform_system.c> In platform/ext/target/arm/corstone1000/CMakeLists.txt is wrong because it uses TFM_PARTITION_PLATFORM but should use ${ TFM_PARTITION_PLATFORM } If so then maybe platform maintainers can fix this. 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>

2 years

1
0
0 0

Recommended GNU compiler version

by Quach, Brian

Is 11.2-2022.02 the recommended compiler version? I saw TF-M v1.8 states: " GNU Arm compiler version *10-2020-q4-major* has an issue in CMSE support. The bug is reported in `here <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157>`__. Select other GNU Arm compiler versions instead. GNU Arm compiler version greater and equal than *11.3.Rel1* has a linker issue in syscall. Select other GNU Arm compiler versions instead. " Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years

3
8
0 0

gateway attribute question

by Quach, Brian

Hi, When is it appropriate to use "__tz_c_veneer" vs. "__tfm_nspm_secure_gateway_attributes__"? The only difference appears to be placing it in "SFN" section. Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

2 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M