June 2024 - TF-M - lists.trustedfirmware.org

by Anton Komlev

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

2 days, 23 hours

8
65
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

2 months, 4 weeks

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

2 months, 4 weeks

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);

3 months, 2 weeks

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

3 months, 2 weeks

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

3 months, 2 weeks

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

3 months, 2 weeks

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

3 months, 2 weeks

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.

3 months, 2 weeks

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

3 months, 2 weeks

4
9
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M June 2024