- TF-M - lists.trustedfirmware.org

by Bohdan.Hunko＠infineon.com

Hi everyone, TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH. This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation: 1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file). 2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF) 3. Scatter files does not account for HIGHEST priority (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3 So I have several questions on this topic: 1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. 2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py 3. Should scatter files be fixed to account for HIGHEST priority? 4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? 5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around. 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>

3 years, 7 months

2
2
0 0

PSA arch test problem

by Bohdan.Hunko＠infineon.com

Hi, Lately I have been working with PSA arch tests and found few issues with them: 1. PSA arch tests build on Windows fails. I am using the following command: cmake -S . -B build_gcc_psoc64 -G"Unix Makefiles" -DTFM_PLATFORM=cypress/psoc64 -DTEST_PSA_API=INITIAL_ATTESTATION This is true for all the compilers and build types. I have also tried building Musca B1 and the results are the same. Is this expected behavior? Are PSA arch test meant to be built on windows? 2. I have tried building PSA arch tests with IAR on both Linux and Windows and it does not work. From quick investigation it looks like IAR is not supported. Am I right? And if so the is there a plan to support PSA arch tests for IAR compiler? 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>

3 years, 7 months

6
15
0 0

Proposal for Musca-B1 SE deprecation

by Anton Komlev

Hello, We would like to propose removing the Musca-B1 Secure Enclave platform configuration* in TF-M. This solution was developed to demonstrate the PSA Configuration to support the TF-M Secure Services on Secure Enclave providing Secure Services to the Host processor running non-secure application. Musca-B1 SE was the foundation of the Corstone-1000** solution, which provides a secure enclave implementation that is also PSA L2 Ready Certified. Please reply if there are any concerns deprecating and removing the Musca-B1 SE configuration from TF-M . Process for deprecation and removal of platforms can be found here https://tf-m-user-guide.trustedfirmware.org/platform/ext/platform_deprecati… * https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/musca_b… ** https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/arm/corston… Thanks, Anton

3 years, 7 months

1
1
0 0

Manifest files questions

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to manifest files in TFM: 1. Currently TFM dos not support dynamic memory allocation, so heap_size manifest field is a bit special. Presence of heap_size field for library model will generate error in tfm_spm_db_func.inc.template but when TFM_PSA_API is ON heap_size is used in partition_load_info.template which will silently set .heap_size struct field to 0 without generation of any error. As dynamic memory allocation is not supported I think error should be generated in both files. Also I think that error should only be generated if heap_size filed is present and is not "0" (if it is not present or is 0 then no error should be generated because it is compliant with "no dynamic memory rule") 2. Manifest files support numbered mmio regions for partitions. Example "mmio_regions": [ { "base": "MY_CUSTOM_REGION_BASE", "size": "MY_CUSTOM_REGION_SIZE", "permission": "READ-WRITE" } ] The questions is why doesn't TFM use this field for ITS and PS areas instead of handling them manually? Can this be reworked to use mmio regions? If so then is this work planned and when approximately it will be done? 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>

3 years, 7 months

2
1
0 0

Library fetching improvements

by Bohdan.Hunko＠infineon.com

Hi, Recently I have been adding some new libraries to my TFM project and what I always end up doing is: go to some existing file which fetches the library, copy code from there, paste it to my file, change few links, versions and names. It is a bit annoying to copy-paste that code each time, also it is hard to maintain (if pattern for fetching libraries changes) and also copy pasting might lead to some code not being updated. My proposal is to have a function that can be used to fetch a library. This way it will be easier to add new libraries and this change will make code cleaner. Please let me know your thoughts on this proposal. 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>

3 years, 7 months

5
8
0 0

Automatically copy RAM_VECTORS when using ARMClang and IAR

by Bohdan.Hunko＠infineon.com

Hi, When poking around some startup files I have found interesting place related to RAM_VECTORS support CMSIS have __PROGRAM_START macro which is different for each compiler. For GCC it uses __cmsis_start, for ARMClang - __main and for IAR - __iar_program_start Basically each of the functions should copy several sections (.TFM_DATA for example) from FLASH to RAM and zero out some parts of RAM (for .TFM_BSS for example) In current implementation GCC __cmsis_start function also copies the vector table from FLASH to SRAM (if RAM_VECTORS are enabled) But ARMClang and IAR equivalents of that function (__main, __iar_program_start) does not seem to take care of copying vector table, so platforms startup should do that I wonder if there is a way to change linker script in a way which will make copying of vector table automatic (by compiler dependent function). This will make platform startups a bit cleaner and will allow platform to just use __PROGRAM_START macro without any additional code to copy vector table. From what I see IAR has "initialize by copy" syntaxis so I think it may be used to tell IAR to automatically copy vector table. It is a bit more tricky with ARMClang as I have not found a way to do that there. I am not a big expert in ARMClang and IAR so maybe someone may help me here, give some directions or confirm that currently there is no way to make this idea work. Basically the intention is to simplify platform startup code and offload common operations to compiler specific platform independent functions. 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>

3 years, 7 months

2
5
0 0

FW: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022-07-07 23:00 UTC to 2022-07-08 03:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Sent: Wednesday, July 6, 2022 2:02 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08 Hello All, The server will be offline to start a maintenance window on 2022-07-08 at 01:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-07 23:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade to Jenkins 2.332.3. The upgrade will address several security advisories for Jenkins core and its plugins and will also bring the server to feature parity with staging. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-08 01:00 UTC End: 2022-07-08 03:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

3 years, 7 months

1
0
0 0

Ask for review on TF-M memory check interface update patch

by Summer Qin

Hi, I have sorted out memory check functions and done some refinement. As it covers all the platforms, may I ask for a review on these patches<https://review.trustedfirmware.org/q/topic:%22memory-check-interface-update…>? I would like to merge it by 30th of this month if possible. Thanks so much! Best Regards, Summer

3 years, 7 months

1
0
0 0

PS partition dependencies

by Chris.Brand＠infineon.com

I'm experimenting with a build with the SFN backend, and I've hit an error. cmake -S . -B build_musca_sse200_GNUARM_Release -DTFM_PLATFORM=arm/musca_b1/sse_200 -DCONFIG_TFM_SPM_BACKEND=SFN -DTFM_PARTITION_PLATFORM=OFF -DTFM_PARTITION_FIRMWARE_UPDATE=OFF -DPS_ROLLBACK_PROTECTION=OFF cmake --build build_musca_sse200_GNUARM_Release results in .../build_musca_sse200_GNUARM_Release/generated/secure_fw/partitions/protected_storage/auto_generated/load_info_tfm_protected_storage.c:85:9: error: 'TFM_SP_PLATFORM_NV_COUNTER_SID' undeclared here (not in a function); did you mean 'TFM_SP_NON_SECURE_ID'? TFM_SP_PLATFORM_NV_COUNTER_SID, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TFM_SP_NON_SECURE_ID Config/check_config.cmake line 93 is tfm_invalid_config((TFM_PARTITION_PROTECTED_STORAGE AND PS_ROLLBACK_PROTECTION) AND NOT TFM_PARTITION_PLATFORM) but secure_fw/partitions/protected_storage/tfm_protected_storage.yaml lists TFM_SP_PLATFORM_NV_COUNTER as a dependency unconditionally. The easy fix is to change check_config.cmake to have the PS partition unconditionally require the platform partition, but it seems that the intent is that it should still be possible to enable PS without rollback protection. Chris Brand Cypress Semiconductor (Canada), Inc. An Infineon Technologies Company Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> International Place 13700 V6V 2X8 Richmond Canada www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies> Part of your life. Part of tomorrow. NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.

3 years, 7 months

2
1
0 0

Ask for review on TF-M patch

by Sherry Zhang

Hi, I have created a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/> which removes the unnecessary heap(including the RAM memory reserved for heap and the heap related symbols). As it covers all the platforms and compilers, may I ask for a review on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15313/>? This patch saves about 680 bytes Flash while 4200 bytes RAM. I would like to merge it by 29th this month if possible. Thanks so much! Regards, Sherry Zhang

3 years, 7 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M