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

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 week, 2 days

2
4
0 0

Documentation improvements

by Anton Komlev

Hello, The project documentation will never be ideal and we are continuing improving it. Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase. Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful. Thank you in advance, Anton

1 week, 3 days

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

4 weeks, 1 day

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>

1 month, 1 week

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

1 month, 1 week

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

1 month, 1 week

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>

1 month, 1 week

2
5
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

1 month, 2 weeks

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.

1 month, 2 weeks

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

1 month, 2 weeks

1
0
0 0

2022

2021

2020

2019

2018

TF-M June 2022