July 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

1 day, 18 hours

12
92
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 year, 2 months

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

1 year, 9 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.

1 year, 11 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>

1 year, 12 months

4
10
0 0

PSA Crypto headers for v8-M TrustZone Solution - feedback gathering

by Antonio De Angelis

Hi all, following up on the presentation I gave on last tech forum (https://www.trustedfirmware.org/docs/PSACryptoHeader_June23_Antonio_shareab…) and related discussion (https://linaro-org.zoom.us/rec/share/1bBb9d06OWPACMtT_wC6C336k2Y0oeAtbM5REG… , passcode: *%RuR8Q8), I'd like to start this thread to collect feedback on TF-M's current solution as a candidate for this effort. TF-M's headers: psa « include « interface - trusted-firmware-m.git - Trusted Firmware for M profile Arm CPUs<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/interface/…> I plan to discuss the feedback received in one of the coming tech-forums (but likely not next week's). Thanks, Antonio

2 years, 1 month

2
1
0 0

S/MIME email certificate usage in Mbed TLS library

by nagarajan.rak＠gmail.com

Our requirement is to send email securely from our embedded device running on STM32H7 processor. There's an SMTP client application (implemented using Mbed TLS library) running on this device, which will send emails to the recipient via custom/public email server such as smtp.gmail.com. We are planning to use S/MIME email certificate from the one of the Trusted CA, for encryption of the email message and authentication of the client/server. We learnt that each S/MIME email certificate support only one email address, but we will be having multiple devices running on the field and each device will have unique email address from which email will be sent. Getting S/MIME email certificate for device will not be feasible, is there any better way we can handle this scenario effectively. Your response to this problem is greatly appreciated. Thank you, Nagaraj

2 years, 2 months

2
1
0 0

Hybrid platforms discussion follow up.

by Anton Komlev

Hi, On the last tech forum (June 22) we started discussion on multicore hybrid platforms. By this mail I’d like to follow up and continue offline analyses on new use-cases and requirements for TF-M design update. The recorded session is available here: https://linaro-org.zoom.us/rec/share/yseF-mYwUTtHHPkQJQO6IEv72xCd0Lz1pQQecc…, Passcode: 5s=Npv=w and slides: https://www.trustedfirmware.org/docs/tech_forum_20230622_Hybrid_platforms.p… The current plan is to take time, think on the use-cases and map them on requirements. With more thought and materials, we will have another session about September time to define our needs in the support of new type of platform. Please share your thoughts in reply. Thanks, Anton

2 years, 2 months

3
3
0 0

Design update: Choose ABI for partition interfaces by checking boundaries

by Xinyu Zhang

Hi, We are planning to update the mechanism on partition interface ABI selection in IPC model. In current Implementation, cross call ABI is chosen in Isolation Level 1, and SVC call ABI is chosen in Isolation Level 2&3. However, interfaces are actually the bridge between SPM and caller partitions. If one partition shares the same boundary with SPM, cross call ABI is the choice; while if one partition does not share the same boundary with SPM, a SVC ABI is the proper choice. But, a simple comparison between two boundary values cannot be used for checking if the two boundaries are the same one - these values might be encoded with bit fields and contains more info than memory regions. Hence the comparison should be done by who generated them - the isolation HAL implementation in platform sources. So here comes to the following design: 1. In HAL function tfm_hal_bind_boundary, encode p_ldinf into boundary value, so that there is no need to pass both p_ldinf and boundary value to switch boundary. 1. Implement a HAL function to compare boundaries and switch boundary if needed. tfm_hal_status_t tfm_hal_switch_boundary( uintptr_t target_boundary, uintptr _t current_boundary, uint32_t compare_only, /* 0: Switch boundary if they are different, 1: Only compare whether the boundaries are different and do not switch */ uint32_t* compare_result); /* Tell the caller whether the boundaries are different */ 1. Select correct type of ABI when processing metadata of partition based on boundary. void prv_process_metadata(struct partition_t *p_pt) { ... tfm_hal_switch_boundary(SPM_BOUNDARY, p_pt->boundary, 1, *compare_result); if (compare_result == 1) { p_rt_meta->psa_fns = &psa_api_svc; } else { p_rt_meta->psa_fns = &psa_api_cross; } ... } Please let us know if you have any suggestion. Thanks, Xinyu

2 years, 2 months

1
0
0 0

FYI: Session on OpenCI and MISRA

by Don Harbin

Hi All, I wanted to let you know that next Thursday, July 27th, the TF-A Tech Forum will be hosting a presentation on OpenCI and MISRA presented by Paul Sokolovski of Linaro and Roberto Bagnara from Bugseng. MISRA is being enabled on both TF-A and TF-M in OpenCI, so sending this out to both lists since users in both domains may be interested in the session. Meeting time and dial up info can be found in the TF community calendar located here: https://www.trustedfirmware.org/meetings/ Best Regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M July 2023