January 2023 - 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, 19 hours

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

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

9 months, 2 weeks

3
4
0 0

Split build

by Bohdan.Hunko＠infineon.com

Hi everyone, Some time ago patch for split build<https://review.trustedfirmware.org/q/topic:%2522split-build%2522> of SPE, NSPE, BL2 was announced. I am interested on when this patch is planned to be merged? 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, 4 months

4
5
0 0

Partitions without manifest files are not linked correctly in L3

by Bohdan.Hunko＠infineon.com

In isolation level 3 partitions code/data in linker script are gathered together and aligned using information from manifest files. Currently there are 2 partitions that are not using manifest files, and instead have hand written load_info.c files. These partitions are: NS agent trust zone and idle partition. When partition does not have manifest file then its code/data is not gathered together (as there is no manifest to provide needed information). This results in partition code/data being linked directly to SPM. Also code/data may be not correctly aligned (if platform requires special alignment for PSA/APP RoT partitions). For example if platform define custom TFM_LINKER_PSA_ROT_LINKER_DATA_ALIGNMENT, NS agent TZ and idle partitions stacks will not be aligned properly. This is a problem because resulting alignment is not sufficient for the platform, which means that functions that apply protections fail. I see several solutions to this problem: 1. Add alignment to stack of these special partitions. Both the start and the size of the stack should be aligned to satisfy alignment requirements. This is fairly easy fix with small amount of changes. The problem is that code/data of these partitions will still be located in SPM code/data sections which is not ideal solution. I would say this is bare minimum solution, just to make things work. 2. Better solution might be to move these special partitions to now use manifest files. The problem I see is that these partition use special priorities values which are not supported by manifest tool. Also NS Agent TZ uses special PID = 0, which I believe is also not supported by manifest tool. I think this is more time consuming fix but overall this should result in better and easier to understand code. Would be glad to hear a feedback on this topic. 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

2
3
0 0

Default implementation of tfm_ns_interface_dispatch()

by Bohdan.Hunko＠infineon.com

Hi all, While working on TFM TZ related stuff I have noticed that TFM docs/integration_guide/index.rst states that * On Armv8-M TrustZone based platforms, NS OS shall implement interface API ``tfm_ns_interface_dispatch()`` to integrate with TF-M implementation of PSA APIs. But currently neither CMSIS RToS nor FreeRToS implements this function, also there is no default implementation for bare metal case. So currently it is user responsibility to implement this function. Also currently for TFM tests it is implemented in test repository (<tf-m-tests repo>/ app/tfm_ns_interface.c). I think this is bad user experience because each user have to implement this function. I think TFM should provide implementation of this function for most common use cases (for example, CMSIS RToS, AWS FreeRToS, bare metal, ...). Files with implementation should be installed during build process. Default implementations will cover most of use cases and will fit for majority of the users. This way TFM will be more user friendly. What are your thoughts on this topic? Will TFM accept such a patch? 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

3
10
0 0

RSS target platform

by Peter Sawicki

Hi, I wonder which target platform is used to run RSS. According to the https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/readme.html it's a Total Compute platform. But there are two FVPs i.e. TC1 and TC2, both available on https://developer.arm.com/downloads/-/arm-ecosystem-fvps. They are equipped only with SCP. I suppose that this is TC2, which is currently not publicly available ("HW Root of Trust based on the TF-M RSS subsystem." a cite from https://arm-reference-solutions-docs.readthedocs.io/en/tc2-2022.12.07/docs/…) Is the TC2 the only target that is currently used for RSS development? Kind regards, Peter

1 year, 8 months

2
6
0 0

Region Limits

by Chris.Brand＠infineon.com

Hi, Looking at platform/ext/common/tfm_hal_platform_v8m.c, this line stands out as quite odd: .veneer_limit = (uint32_t)&REGION_NAME(Image$$, VENEER_ALIGN, $$Limit) - 1, It seems that the various "$$Limit" values that exist within TF-M aren't actually "limits" in the usual meaning of the word (the last value within the range) but are instead the first value *outside* the range. Elsewhere in TF-M we do seem to use the word "limit" in the conventional way. I worry that this could lead to errors around the boundaries, particularly as some functions we use to check ranges take a "limit" parameter - we could easily see code that looks correct but that actual does the wrong thing, like ARM_MPC_ConfigRegion(REGION_NAME(Image$$, ER_VENEER, $$Base), REGION_NAME(Image$$, VENEER_ALIGN, $$Limit, attr); Or a similar call to check_address_range(). For example, I suspect that this is a bug in the Nuvoton M2354 platform caused by this issue: platform/ext/target/nuvoton/m2354/target_cfg.c: .veneer_limit = (uint32_t)&REGION_NAME(Image$$, VENEER_ALIGN, $$Limit), It's obviously a big thing to fix, but it does look to me to be worthwhile... 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 year, 8 months

3
4
0 0

Disable FLIH tests in CI

by Xinyu Zhang

Hi All, it is spotted that FLIH tests failed recently and blocks CI verification. We need to dig into it and found the reason. To avoid blocking the daily work, we will temporarily turn FLIH tests off, and recover when solved. Background: Sometimes the test application stuck in waiting for interrupts even the interrupt is properly configured. If someone got solutions for similar problems please share your info, thank you in advance. Best Regards, Xinyu

1 year, 8 months

1
0
0 0

MbedCrypto linking problem in isolation L3

by Bohdan.Hunko＠infineon.com

Hi all, After having some troubles with isolation level 3 I have noticed that MbedTLS (mbedcrypto) data/code is not properly linked to crypto partition. Currently mbed crypto data/code is placed into SPM data/code section in level 3 isolation. This is a problem if optional L3 FFM boundaries are applied (when SPM is isolated from PSA RoT partition (Crypto in particular)) because in this case crypto partition does not have access to the mbedcrypto code/data that is located in SPM code/data sections. I think Mbedcrypto data/code should be linked to crypto partition and placed in crypto partition linker section. This way it will be protected to be accessible by crypto partition. So my question is whether this should be fixed or there are objectives to not fix this issue? If fix is needed I would like to discuss possible ways to solve this 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, 8 months

2
6
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M January 2023