May 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

14 hours, 22 minutes

7
56
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 week

10
58
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

5 months

3
4
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.

7 months

3
8
0 0

Dependency on generated files is broken

by Bohdan.Hunko＠infineon.com

Hi all, Seems like dependency on generated files is broken. Steps to reproduce: 1. Build any platform at any mode 2. Change any .template file 3. Expected result: 1. New file is generated from the updated .template file Actual result: 1. Generated files step is skipped. My best guess will be that 1ce59292a47b1316e5d8b4d28bcaf9d8e2bdc0a5 broke it. Could 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>

7 months, 3 weeks

4
10
0 0

ARMCLANG protections bug

by Bohdan.Hunko＠infineon.com

Hi all, In GCC linker scripts ands of sections are aligned using following syntax: . = ALIGN(TFM_LINKER_XXX_ALIGNMENT); But in ARMClang TFM does not use similar approach, instead it creates Position tags sections like following: TFM_APP_CODE_START +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } TFM_APP_ROT_LINKER +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT { *tfm_app_rot_partition* (+RO-CODE, +RO-DATA) *libplatform_s* (TFM_*_APP-ROT_ATTR_FN) *.o (TFM_*_APP-ROT_ATTR_FN) } /* * This empty, zero long execution region is here to mark the end address * of APP RoT code. */ TFM_APP_CODE_END +0 ALIGN TFM_LINKER_APP_ROT_LINKER_CODE_ALIGNMENT EMPTY 0x0 { } I believe this is done because clang does not have syntaxes for aligning end of the section (please correct me if I am wrong). This approach results in bug in TFM_UNPRIV_CODE section protections, because TFM_UNPRIV_CODE Base and Limit are used directly and Limit is not aligned. For now this problem stayed undetected because present platforms does not validate region_limit when applying protections. I have created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21169> , which adds validation of region_limit and ran Ci on it and I can see that CI failed in tests for Clang builds So I guess this is the problem that have to be fixed. I see following possible solutions: 1. Align and of TFM_UNPRIV_CODE section (but I guess clang does not support that) 2. Add position tags for _START and END Solution 1 will simpler as it will not require changed in platform code, but I guess clang syntaxes is limiting us here. So my question would be whether there is a plan to fix this issue ? 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>

11 months, 1 week

2
2
0 0

Using bitwise or (|) / and (&) in Clang scatter file

by Bohdan.Hunko＠infineon.com

Hi For our platform we use some ,across which should set/clear bit 28 of an address (see code below). We do this for convenience reasons. #define IFX_S_ADDRESS_ALIAS(x) ((x) | 0x10000000) #define IFX_NS_ADDRESS_ALIAS(x) ((x) & ~0x10000000) Those macros are used in declaration of S_CODE_START macro. When expended in linker script (tfm_isolation_l3.o), the declaration of LR_CODE section looks as follows: LR_CODE (0x24000000 | 0x10000000) (0x4B000) { This code results in following error: tfm_isolation_l3.o", line 46 (column 21): Error: L6292E: Ignoring unknown attribute '|' specified for region LR_CODE. I tried experimenting with this and found out that when | is changed to or (see following code) then linker works fine: LR_CODE (0x24000000 or 0x10000000) (0x4B000) { Same problem is present when using bitwise and (&). But when using bitwise NOT (~0x...) everything works fine. Having to define our macros in different way brings some problems for our platform, so maybe someone knows how to solve this problem? Maybe there are compilation flags or something like that? Ideally we want | and & to work fine in linker script. Thanks! 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>

11 months, 2 weeks

2
2
0 0

Branch release/1.7.x to be deleted

by Anton Komlev

Hi, I plan to delete the branch release/1.7.x at the end of this week (after May 26) following TF-M release process<https://tf-m-user-guide.trustedfirmware.org/releases/release_process.html#r…>. Please let me know if someone is dependent on it and needs more time to detach from it. Thanks, Anton

12 months

1
0
0 0

psa_call performance

by Quach, Brian

Hi, Using isolation level 1 and IPC secure partition, I noticed psa_call() overhead for TFM v1.7 is significantly worse for than v1.1. Is this expected? Assuming 1 invec and 0 outvec for the PSA call.... TF-M version Psa_call() round trip cycles v1.1 4038 v1.7 6051 Regards, Brian Quach SimpleLink MCU Texas Instruments Inc.

12 months

6
16
0 0

Querying Anyone Using Shared Memory to Share Lifecycle, Bootseed, Hardwareversion Info

by Sherry Zhang

Hi, Currently in the Attestation partition, when encoding the security lifecycle, boot seed, and hardware version claims, these info are searched in the shared memory firstly before calling the platform hal APIs. See the code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Sharing this information via shared memory is a legacy mechanism and MCUboot does not writes that information when booting. And calling the platform hal APIs way is recommended. I created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/21021> removes looking for the security lifecycle, boot seed, and hardware version from shared memory. Before opening this patch for review, I would like to query whether this mechanism is being used by any platform. Is there any platform(which suppose runs a bootloader which is not MCUboot) using this sharing memory mechanism to provide the security lifecycle, boot seed, and hardware version information now? Thanks, Regards, Sherry Zhang

12 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M May 2023