December 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

2 days, 2 hours

10
57
0 0

Technical Forum call - July 21

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

7
55
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 months, 3 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>

11 months, 3 weeks

4
5
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, 2 months

3
10
0 0

minor bug in an521 protections

by Bohdan.Hunko＠infineon.com

Hi, I have been working on TZ stuff recently and found small problem in an521 platform protections. The problem is in SAU config. sau_cfg in platform/ext/target/arm/mps2/an521/target_cfg.c has entry for NSPE code: { ((uint32_t)NS_PARTITION_START), ((uint32_t)NS_PARTITION_START + NS_PARTITION_SIZE - 1), false, }, Where both NS_PARTITION_START and NS_PARTITION_SIZE are 32 bytes aligned, which means that when 1 is subtracted lower 5 bits are getting set to 1, for example: 0x1000_0000 + 0x1000 - 1 = 0x10000FFF Then in sau_and_idau_cfg() function lower 5 bits are cleared by the mask: sau_cfg[i].RLAR & SAU_RLAR_LADDR_Msk This means that in reality highest 32 bytes of NSPE are protected as Secure in SAU. Same problem is present for SECONDARY_PARTITION_SIZE SAU entry. This is not huge problem, but still worth fixing. I believe other arm and TZ platforms may also have this bug, but I haven't checked in details. 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

3
6
0 0

SAU region setting check request

by Ken Liu

Hi, It is reported in a few platforms that the SAU NSC region limit is set 32 bytes larger than expected because the value set did not match the hardware characteristics. The SAU.LADDR treats the last 5 bits as 0x1 which means a valid limit address should be the value with 0x1f in the last bits, take an example if the region starts at 0x1000 with size 0x100, the limit address should be set as 0x1000 + 0x100 - 0x20 which is 0x10E0. The practical region address range is [0x1000 - 0x10FF], all addresses >= 0x1000 and <= 0x10FF would be treated as hitting a region. If your address and size are 32 bytes aligned already, you can just adjust the limit with "start_address + size - 1", as the tailing 5 bits would be masked. Take this patch as an example: Platform: Fix the Veneer SAU region for Arm platforms (I2692f318) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/18547> Now only the NSC region is affected, but please check your platform if you are using SAU to see if each region is set properly. Thanks. /Ken

1 year, 4 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi, Sorry to inform you that TF-M Open CI is down. We are trying hard to fix. We'll let you know once it is back to normal. Best Regards, Xinyu

1 year, 4 months

1
1
0 0

Multi slot queue in bare metal NSPE

by Bohdan.Hunko＠infineon.com

Hi all, TFM in current implementation has following condition in tfm_ns_mailbox.h #if !defined(TFM_MULTI_CORE_NS_OS) && (NUM_MAILBOX_QUEUE_SLOT > 1) #error "NUM_MAILBOX_QUEUE_SLOT should be set to 1 for NS bare metal environment" #endif I was wondering whether this is real restriction or this check can be removed. I am not mailbox expert so please correct me if I am wrong. Quick look at the code shows that it should be ok to have multi slot queue in bare metal environment, with the note that only one slot will be used (as there is only one thread). If my understanding is correct then it would be nice to remove this compile time check (I am happy to provide a patch for it). We need this change because we deliver TFM as prebuilt binary and interface (one installed after the build). This binary is built with NUM_MAILBOX_QUEUE_SLOT = 4, so in current implementation it cant be used in bare metal environment. 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

2
1
0 0

FW: [Maintenance] - ci.trustedfirmware.org down time 2022-12-16

by Xinyu Zhang

Hi, FYI. TF-M Open CI will be on maintenance on 16th Dec. Time to stop triggering new jobs: 2022-12-16 18:00 UTC Maintenance end time: 2022-12-16 22:00 UTC Regards, Xinyu From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, December 15, 2022 4:16 AM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.trustedfirmware.org down time 2022-12-16 Hello All, The server will be offline to start a maintenance window on 2022-12-16 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-12-16 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade for Jenkins to address some security advisories and enable new functionality. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 12-16 20:00 UTC End: 2022-12-16 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org<mailto:kelley.spoon@linaro.org>>

1 year, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M December 2022