- TF-M - lists.trustedfirmware.org

FW: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022 07-22 18:00 UTC to 2022-07-22 22:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org> Sent: Thursday, July 21, 2022 10:14 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci-triage] [Maintenance] - ci.staging.trustedfirmware.org down time 2022-07-22 Hello All, The server will be offline to start a maintenance window on 2022-07-22 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-22 18:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to add a plugin to Jenkins to support new functionality required for a service being developed. The version of Jenkins and the plugins currently being run will not be changing. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-22 18:00 UTC End: 2022-07-22 22:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci-triage mailing list -- tf-openci-triage(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-triage-leave(a)lists.trustedfirmware.org

2 years, 11 months

1
0
0 0

ns_agent flag

by Chris.Brand＠infineon.com

In https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… Ken mentions the need for a special flag in the manifest to indicate a non-secure agent partition. The code change is fairly easy, I think, but the manifest file format is specified by PSA, and presumably would also need to change. How do we go about doing that? Thanks, 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.

2 years, 11 months

2
1
0 0

Last call for comments on patch 15362

by Chris.Brand＠infineon.com

Hi, We'd like to merge https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15362 which makes a small modification to all platform configs (TFM_CONFIG_USE_TRUSTZONE and TFM_MULTI_CORE_TOPOLOGY lose their default values and must be specified for every platform). 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.

2 years, 11 months

1
0
0 0

Re: [TF-A] Re: Rebooting LTS discussion

by Varun Wadekar

Hi Everyone, We presented a proposal at the Tech Forum yesterday to take the LTS idea forward. The recording link and password are provided below. This effort is important for the project, and we don't want to rush into something that is not useful. With holidays and other engagements, we want to provide more time to digest the information and provide feedback. We will schedule another Tech forum discussion in September to hear feedback/concerns/questions. See you soon! -Varun Recording: https://linaro-org.zoom.us/rec/share/wYFz4jQvpLZntYSamyjc5-n_bGNcx_RFm-amEd… Passcode: NUx82^W= From: Joanna Farley <Joanna.Farley(a)arm.com> Sent: Wednesday, 22 June 2022 3:05 PM To: Varun Wadekar <vwadekar(a)nvidia.com>; Okash Khawaja <okash(a)google.com> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Hi Everyone, I learnt today that our peer project (TF-M) are having a similar LTS discussion and have their own LTS Tech forum session tomorrow. Its an 8am BST(GMT+1) meeting start but I'm told the LTS discussion is mid agenda so expect the discussion on that to start around 8:30am. I'm told it's an information gathering session rather than a proposal session. Anyway the Zoom id of the call is below. These are recorded like TF-A sessions and will be uploaded to their Techforum page. Joanna This event has been changed with this note: "Extending end date" TF-M Tech forum When Changed: Every 4 weeks from 12am to 1am on Thursday Mountain Standard Time - Phoenix Where https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinaro-or…> (map<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…>) Calendar anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> Who * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> * anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> * leonardo.sandoval(a)linaro.org<mailto:leonardo.sandoval@linaro.org> * abdelmalek.omar1(a)gmail.com<mailto:abdelmalek.omar1@gmail.com> more details ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> About TF-M Tech forum: This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward it to colleagues. Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> ====Zoom==== Topic: TF-M Tech forum - Asia Time Zone Friendly Time: Nov 12, 2020 07:00 AM Greenwich Mean Time Every 4 weeks on Thu, until Mar 4, 2021, 5 occurrence(s) Nov 12, 2020 07:00 AM Dec 10, 2020 07:00 AM Jan 7, 2021 07:00 AM Feb 4, 2021 07:00 AM Mar 4, 2021 07:00 AM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJYodOyvpz8jGNEc_1ykVap8Zg6oTLqZZSeJ/ics…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Join Zoom Meeting https://linaro-org.zoom.us/j/92535794925?pwd=TTl0cmo4R2hTNm8wcHo1M3ZKdjlnUT…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Meeting ID: 925 3579 4925 Passcode: 414410 One tap mobile +12532158782,,92535794925# US (Tacoma) +13462487799,,92535794925# US (Houston) Dial by your location +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 9128 US (San Jose) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 925 3579 4925 Find your local number: https://linaro-org.zoom.us/u/aesS64I7GW<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.googl…> Going (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>)? All events in this series: Yes<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - Maybe<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> - No<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> more options ><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> Invitation from Google Calendar<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> You are receiving this courtesy email at the account anton.komlev(a)arm.com<mailto:anton.komlev@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcalendar.…> and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.g…>. From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Date: Tuesday, 21 June 2022 at 18:11 To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Thanks Varun and Okash. I'll update Jul 14th invite and add LTS as the discussion area. From: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Date: Tuesday, 21 June 2022 at 17:24 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: RE: [TF-A] Re: Rebooting LTS discussion Hi Joanna, Thanks for the update. Okash and I would be ready by July 14. We will prepare the slides for the session. -Varun From: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Sent: Tuesday, 21 June 2022 5:07 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Subject: Re: [TF-A] Re: Rebooting LTS discussion External email: Use caution opening links or attachments Okash, Varun, Any thoughts when you want to do a LTS TechForum session. 30th June is now taken and the next scheduled one after that is 14th July. We could try and do a special one on 7th July if that's better. I'm reliant on you guys to jointly prepare and present a LTS TF-A Tech forum session Joanna From: Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Monday, 6 June 2022 at 13:47 To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Cc: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Okash, The next session after next week is Thursday 30th June at 4pm BST. This is also available with nothing currently scheduled. Joanna From: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>> Date: Monday, 6 June 2022 at 13:34 To: Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>, Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: Re: [TF-A] Re: Rebooting LTS discussion Hi Joanna and Varun, Sounds good to me. I will be out of country during next week. After that should be fine. Thanks, Okash On Mon, Jun 6, 2022 at 12:13 PM Joanna Farley <Joanna.Farley(a)arm.com<mailto:Joanna.Farley@arm.com>> wrote: Varun, Okash, I believe the two of you have some interest in the LTS topic. Would the two of you be willing to jointly prepare and present a TF-A Tech forum session? The next available session is Thursday 16th June at 4pm BST. I'm sure there are many definitions of what a LTS release branch is in terms of purpose, content, duration etc. I would expect many platform providers are doing this downstream today and I could imagine there may be variations. Some degree of consensus on how this is managed and resourced would be needed I believe between multiple platform providers who would want to consume this. It would be good to see issues raised for discussion. I'm happy to host if the two of you and any other platform providers interested can prepare a TF-A session to present to the broader TF-A community. Thanks Joanna From: Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Date: Tuesday, 31 May 2022 at 15:23 To: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>>, Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>, tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> Subject: [TF-A] Re: Rebooting LTS discussion Hi Matteo/Okash, Thanks for re-starting the discussion. We (NVIDIA) are still interested in the idea and would like to discuss the next steps. I like the idea of a hotfix release, although would propose back-porting fixes to more tags. A targeted tech forum or another mechanism works for me. I would like to discuss the scope of the activity and the engagement model. -Varun -----Original Message----- From: Matteo Carlini <Matteo.Carlini(a)arm.com<mailto:Matteo.Carlini@arm.com>> Sent: Tuesday, 17 May 2022 3:39 PM To: Okash Khawaja <okash(a)google.com<mailto:okash@google.com>>; tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>; raghu.ncstate(a)icloud.com<mailto:raghu.ncstate@icloud.com> Subject: RE: [TF-A] Rebooting LTS discussion External email: Use caution opening links or attachments Hi Okash, Thanks for rebooting the conversation. Out of the brainstorming from 1.5 yrs ago, we had this page published with an initial RFC proposal for LTSs: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…> Worth mentioning that, in the meanwhile, the TF-M project has introduced the concept of Hotfix releases (which is a very lightweight process for backporting critical bug fix/security fixes only to the last available tagged release): https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftf-m-user…> I'm curious to hear others' opinion and interest (@Varun, @Raghu ?) to possibly revive this topic in either in a Tech Forum or at a project TSC/Board level. Thanks Matteo -- TF-A mailing list -- tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org<mailto:tf-a-leave@lists.trustedfirmware.org>

2 years, 11 months

2
1
0 0

Partition priority questions

by Bohdan.Hunko＠infineon.com

Hi everyone, TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH. This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation: 1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file). 2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF) 3. Scatter files does not account for HIGHEST priority (see code here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3 So I have several questions on this topic: 1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them. 2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py 3. Should scatter files be fixed to account for HIGHEST priority? 4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority? 5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere? Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around. 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>

2 years, 11 months

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>

2 years, 11 months

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

2 years, 11 months

1
1
0 0

Manifest files questions

by Bohdan.Hunko＠infineon.com

Hi everyone, I have several questions related to manifest files in TFM: 1. Currently TFM dos not support dynamic memory allocation, so heap_size manifest field is a bit special. Presence of heap_size field for library model will generate error in tfm_spm_db_func.inc.template but when TFM_PSA_API is ON heap_size is used in partition_load_info.template which will silently set .heap_size struct field to 0 without generation of any error. As dynamic memory allocation is not supported I think error should be generated in both files. Also I think that error should only be generated if heap_size filed is present and is not "0" (if it is not present or is 0 then no error should be generated because it is compliant with "no dynamic memory rule") 2. Manifest files support numbered mmio regions for partitions. Example "mmio_regions": [ { "base": "MY_CUSTOM_REGION_BASE", "size": "MY_CUSTOM_REGION_SIZE", "permission": "READ-WRITE" } ] The questions is why doesn't TFM use this field for ITS and PS areas instead of handling them manually? Can this be reworked to use mmio regions? If so then is this work planned and when approximately it will be done? 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>

2 years, 11 months

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

2 years, 11 months

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>

2 years, 11 months

2
5
0 0

FW: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08

by Xinyu Zhang

Hi All, FYI. Open CI will be down from 2022-07-07 23:00 UTC to 2022-07-08 03:00 UTC for Jenkins upgrade. Please let us know if there is any problem. Thanks Xinyu -----Original Message----- From: Kelley Spoon via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Sent: Wednesday, July 6, 2022 2:02 PM To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org Subject: [Tf-openci] [Maintenance] - ci.trustedfirmware.org down time 2022-07-08 Hello All, The server will be offline to start a maintenance window on 2022-07-08 at 01:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-07-07 23:00 UTC to stop accepting new jobs and allow executing tasks to complete. This downtime is required to execute an upgrade to Jenkins 2.332.3. The upgrade will address several security advisories for Jenkins core and its plugins and will also bring the server to feature parity with staging. Emails will be sent prior to and following the upgrade to provide status reports. Start: 2022 07-08 01:00 UTC End: 2022-07-08 03:00 UTC Regards, -- Kelley Spoon <kelley.spoon(a)linaro.org> -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

2 years, 11 months

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

2 years, 12 months

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.

2 years, 12 months

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

2 years, 12 months

1
0
0 0

Technical Forum call - June 23 - agenda

by Anton Komlev

Hello, the agenda for the forum tomorrow, June 23, 7:00-8:00 UTC 1. Proposal of External Trusted Secure Storage by Poppy Wu 2. Long Time Support (LTS) in TF-M project: the needs, cadence, scope. Open discussion. 3. AOB 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/ Thanks, Anton

2 years, 12 months

1
0
0 0

Technical Forum call - June 23

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, June 23, 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

3 years

1
1
0 0

Re: Technical Forum call - June 23

by Edward Yang

Hi Anton, I'd like to give a presentation about the proposal of External Trusted Secure Storage, and the presentation will take about 30 minutes, thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> 2022/06/15 20:31 Please respond to Anton Komlev <Anton.Komlev(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject [TF-M] Technical Forum call - June 23 Hello, The next Technical Forum is planned on Thursday, June 23, 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 -- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years

1
0
0 0

Migrate to Mbed TLS PSA configuration scheme

by Summer Qin

Hi, TF-M is going to migrate to Mbed TLS PSA configuration scheme which is recommended by Mbed TLS. With this new feature, TF-M is able to: * more conveniently to align and check TF-M Crypto feature setting against Mbed TLS configuration. * enable the HW crypto accelerator to use PSA drivers and get rid of Mbed TLS software implementation. Therefore, it can decrease the Crypto SW code size for HW accelerator. After migrating to Mbed TLS PSA configuration scheme, TF-M ROM size will save about 6.5kB. The general mbedtls-psa-configuration<https://review.trustedfirmware.org/q/topic:%22mbedtls-psa-configuration%22+…> patches are going to be merged soon. While the HW crypto patch is still under platform owner review until this Friday. It is welcome that if you have any comments and suggestions : ) Best Regards, Summer

3 years

1
0
0 0

Refining TF-M contribution processes

by David Hu

Hi all, I'm refining TF-M contribution processes. Hope it can better support you to contribute to TF-M community. Currently I focus on the following two repos: * Tf-m-extras: specify the tf-m-extras additional requirements. Enable contributor to specify the maintainers. Patch link<https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/15430>. * Trusted firmware-m: simplify the contribution process a bit to align with current development practices. Make it as a general process reference for other TF-M repos. Patch link<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15472>. Can I ask your to take a look at those changes to the processes? Please let us know if any step can be optimized/clarified further. Any feedback is welcome. Best regards, Hu Ziji

3 years

1
0
0 0

TF-M documentation integration

by Anton Komlev

Hello, TF-M documentation reflects the documents in the main TF-M repository (https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs) only. There are 5 other repos (tests, tools, extras, CI) with corresponded docs being good to be linked to the main. Looking for ideas / advice on the best way to do that. The main problem is that Sphinx (the documentation tool) renders files under its configuration directory only, ignoring everything outside of it so reference to external repos is not an easy task. I see several solutions: 1. The main doc points to external files (*.rst) as an external link without rendering it. Like this<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/depend-trace-tool/…>. <-- Simplest way. 2. Create Sphinx doc for each repository, store rendered output in a temporal storage and link the main to generated HTML files. 3. Use intersphinx<https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html> to link across repositories. Again, need rendered docs in each repo and additional preparation. 4. Anything else? Any thoughts or experience to share? Thanks in advance, Anton

3 years

2
3
0 0

Technical Forum call - June 9

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 9, 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

3 years

1
1
0 0

Mis-use of tfm_spm_partition_set_state()

by Chris.Brand＠infineon.com

Looking at the declaration and body of this function, the first parameter is clearly a partition index (index into g_spm_partition_db.partitions[]), and all the call sites in secure_fw/spm/cmsis_func/spm_func.c use it that way. The three call sites in secure_fw/spm/cmsis_func/main.c, though, all pass a PID instead. This happens to work because g_spm_partition_db.partitions[0].static_data->partition_id == 0 and g_spm_partition_db.partitions[1].static_data->partition_id == 1. I don't see anything that guarantees that that will always be true, though. There is a static function get_partition_id() in secure_fw/spm/cmsis_func/spm_func.c that maps from PID to partition index - should that be exported and called to address this? Thanks, Chris Brand .

3 years

2
2
0 0

Mailbox agent redesign

by Chris.Brand＠infineon.com

Hi, Reading https://tf-m-user-guide.trustedfirmware.org/technical_references/design_doc… it mentions the plan to move ns_agent_mailbox to have "a positive valued Partition ID in the manifest" and it also states that "A standard Secure Partition gets errors when calling the Extended API". Given that it will not possible to use the PID to identify the ns_agent_mailbox, how will the Extended API functions know whether the caller is a standard Secure Partition or not? There was a patch https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15142 that introduced a flag to identify the ns_agent_tz partition - would this be similar? Also, is there a plan for which release this functionality is expected to appear? Thanks, Chris Brand

3 years

2
1
0 0

Usage of TFM_SYSTEM_FP cmake variable

by Bohdan.Hunko＠infineon.com

Hi everyone, I have noticed that GCC toolchain uses CONFIG_TFM_FP to determine FP setting while IAR and Clang use TFM_SYSTEM_FP cmake variable. I was not able to find any docs on this variable, and also there is no assignment of this variable in TFM source code (only read operation from this variable). Is this intendent behavior? 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>

3 years

2
4
0 0

psa_connect() return invalid connect handle error

by Edward Yang

Hi experts, We are developing a demo based on TF-M framework, and we also developed an application RoT partition SP1 and a PSA RoT partition SP2. The secure partition SP1 needs calling a SP2's service during SP1's init(), when the SP1_init() calls a SP2 service, as the SP2 partition hasn't been inited, the SP2_init() executes before handling requestS from SP1. But the returned connect handle is an invalid handle, return PSA_ERROR_GENERIC_ERROR. I am wondering why an invalid connect handle is returned? Any hints? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years

2
1
0 0

Non-secure use of NMI

by Andersson, Joakim

Hi. I was looking into a failing test-case in the Zephyr project for the NMI not being processed when using TF-M. The issue is that SCB.AIRCR.BFHFNMINS bit is not set, so the non-secure write to SCB.ICSR.NMIPENDSET is ignored. Is this a decision that was explicitly made for the TF-M configuration to not allow the non-secure application to use the NMI handler? I could not find anything in the TF-M documentation mentioning the NMI. Are there security concerns related to the NMI? Joakim Andersson | Senior R&D Engineer Trondheim, Norway nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…> | devzone.nordicsemi.com<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevzone.n…> Facebook<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> | LinkedIn<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…> | Twitter<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…> | YouTube<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtu…> | Instagram<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> [Nordic_logo_signature]<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nordic…>

3 years

2
1
0 0

Technical Forum call - May 26

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 26, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years

1
1
0 0

tfm_arch_is_priv() is not available for v8arch

by Bohdan.Hunko＠infineon.com

Hi everyone, While looking through TFM code I have noticed that tfm_arch_is_priv() is defined for v6 and v7 in secure_fw/spm/cmsis_psa/arch/tfm_arch_v6m_v7m.h but not defined for v8. Also tfm_arch_v6m_v7m.h is located in secure_fw/spm/cmsis_psa/arch/ folder, while tfm_arch_v8m.h is located in secure_fw/spm/include/. I think that tfm_arch_is_priv() should also be defined for v8 and also tfm_arch_v6m_v7m.h should be moved to secure_fw/spm/include/. If file will be moved then we can clean up some target_include_directories() which used secure_fw/spm/cmsis_psa/arch/ folder. Any thoughts on this? 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>

3 years

2
1
0 0

Re: Enable SPI interrupt in secure partition

by Edward Yang

Hi Kevin, Thanks for your instruction. We're developing an application RoT partition which access a sensor via an SPI interface(Based on RA6M4_EK development board). After commands have been transferred to the sensor, an SPI_TX_INTERRUPT should be triggered, then calls spi_tx_isr(). Now let's put aside binding secure interrupts to each secure partition, just talk about how to enable SPI interrupts in secure world simply. Here is my implementation: 1.Configure this SPI peripheral as secure peripheral. 2.Assign SPI tx and rx interrupts to secure state by setting NVIC->ITNS register. 3.Enable SPI tx and rx interrupts by seeting NVIC->ISER register. But during debug, I found that spi0_tx_isr() (The ISRs are also placed under this application RoT partition's folder) has never been triggered. Is there anything that I miss? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org> 2022/05/17 09:45 Please respond to Kevin Peng <Kevin.Peng(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc Subject [TF-M] Re: Enable SPI interrupt in secure partition Hi Poppy, First-Level Interrupt Handling (FLIH) should be recommended in your use case as you have latency requirements. Here is an example: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… You’ll firstly need to add an “irq” item in the manifest and “handling ” it with “FLIH”: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… And also add the “mmio_regions” item with the associated device (SPI) to give access permissions to the Secure Partition. The IRQ handling should be in the Secure Partition: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/secure_fw/sui… Note that, no PSA APIs are allowed in the handling. Best Regards, Kevin From: Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, May 16, 2022 5:38 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Enable SPI interrupt in secure partition Hi experts, Recently we're developing a demo based on TF-M, this demo involves using SPI module to drive a sensor by sending commands in a secure partition. And we need to enable SPI receive and send interrupt in this secure partition and the latency shall be as small as possible. I am wondering how to implement this secure interrupts. Is there any example code or instrucstions? Thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 1 month

2
1
0 0

Enable SPI interrupt in secure partition

by Edward Yang

Hi experts, Recently we're developing a demo based on TF-M, this demo involves using SPI module to drive a sensor by sending commands in a secure partition. And we need to enable SPI receive and send interrupt in this secure partition and the latency shall be as small as possible. I am wondering how to implement this secure interrupts. Is there any example code or instrucstions? Thanks. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 1 month

2
1
0 0

'memset/memcpy/mem*' API usage in secure firmware

by Ken Liu

Hi TF-Mers, There are several versions of mem* API set in the system. At the very beginning, the whole secure firmware was put in the library model, and it is expected to be self-contained -- at least at the source level as the first step. Hence a 'tfm_mem*' API set is created for secure firmware usage. The same reason for involving 'spm_mem*' in the PSA compliance model. When we designed HAL for SPM, we noticed that SPM HAL actually run in the same domain as SPM, hence we encouraged developers to use 'spm_mem*' in SPM HAL. This brings a bit of difficulty, especially when the platform sources are shared for multiple targets, while other targets do not have 'spm_mem*' API. As 'mem*' is actually common enough (as they are fundamental API of libc), hence redefine the name is applicable only a system is highly self-contained. In our case, using 'mem*' API can bring much convenience. Hence I am thinking to let sources other than SPM use 'mem*' API, they are platform, partitions and runtime libraries. For SPM sources (under secure_fw/spm), a source-level 'spm_mem*' is kept, to keep the possibility to make SPM itself really self-contained. Now it is only source-level because 'spm_mem*' is actually forwarded to 'mem*'. I am creating a patch to change this, and want to know your opinion. Thanks. /Ken

3 years, 1 month

1
0
0 0

Any usage of environment variables in manifest lists

by Kevin Peng

Hi, Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists? I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155>. In the patch the support of environment variables in manifest lists is removed<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/tool…>. Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15155/1/secu…> surrounded with "@") with their values. While configure_file does not recognize environment variables. If you do have environment variables in manifest list, there is an alternative: Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs. Best Regards, Kevin

3 years, 1 month

3
5
0 0

Re: Technical Forum call - May 12 Cancelled

by David Hu

Hi all, I'd like to cancel tech form in May 12 due to empty agenda. Best regards, Hu Ziji From: David Hu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, May 5, 2022 2:11 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - May 12 Hi, (On behalf of Anton) The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Hu Ziji

3 years, 1 month

1
0
0 0

Attestation token new spec

by Tamas Ban

Hi, the initial attestation token implementation is aligned with this specification: https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-05 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://www.ietf.org/archive/id/draft-tschofenig-rats-psa-token-09.html%23t…> 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

3 years, 1 month

1
0
0 0

Under-layer runtime functions in assembly

by Ken Liu

Hi, In one of the past tech forums, we claimed that we don't encourage contribution in common logic in assembly, and one of the patches was abandoned because of this. That patch is designed to improve the memset/memcpy performance. We override these APIs in general because we want the code can be auditable. Then we provided implementations in C, but it shows these implementation does not provide good performance. We want to apply the toolchain provided versions, and looks GNU tool provides the straightest 'byte-copy' version. And armclang involves unnecessary variants which increase the code size a little (not big). Hence we provide a version with 'tiny' optimization in assembly and mark this patch an exception to the review guidelines, as these under-layer functions won't get changed frequently. We are also seeking an ideal way to apply toolchain versions. The patch is here for your review: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13735 Thanks. /Ken

3 years, 1 month

1
0
0 0

Supporting encryption with ITS

by Vasilakis, Georgios

Hello all, I wanted to let you know that I made the PR which adds encryption on ITS files using the methodology that we discussed before. The encryption is happening in a transparent way for the user, and I tried to avoid major changes in the ITS filesystem. Please add yourself as a reviewer and provide feedback if you think that this is an interesting use case for you. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096 Regards, Georgios Vasilakis

3 years, 1 month

1
0
0 0

Technical Forum call - May 12

by David Hu

Hi, (On behalf of Anton) The next Technical Forum is planned on Thursday, May 12, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Hu Ziji

3 years, 1 month

1
0
0 0

TF-M v1.6.0 release

by Anton Komlev

Hello, I am pleased to announce the new v1.6.0 released of TF-M project. New major features are: * MCUboot updated to v1.9.0. * Mbed TLS updated to v3.1.0 (Support all required PSA Crypto APIs). * Enabled Secure Function (SFN) Model Partition compliance in IPC backend. * Interrupt support (both SLIH/FLIH) for the SFN backend. * MM-IOVEC Support for the SFN backend. * The following Secure Partitions are converted to SFN model: * Protected Storage * Internal Trusted Storage * Initial Attestation * FF-M v1.1 SFN Model supported in Profile Small. * HAL Separation of Library Model and IPC/SFN backend. * FP support for Armv8.1-M Mainline for IPC backend. * Simplified build output message and configurable output. * Halting instead of rebooting on panic in debug build type. * Automated testing of MCUboot BL2. * A new driver interface for the CC-312 runtime library as specified in the PSA Unified Driver spec [1]_. * Added reference bootloader stage 1 (BL1) bootloader for certain platforms. * A new CC312 ROM library for the BL1. * Updated documentation structure. The changes tagged by TF-Mv1.6.0 and located in the release/v1.6.x<https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br…> branch at the moment. In short, they will be integrated with the main branch and be available from there. Thanks everyone for contribution, review and support this milestone. Anton

3 years, 1 month

1
0
0 0

Technical Forum call - April 28

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 28, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 1 month

1
1
0 0

Asking for review of external trusted secure storage partition implementation code

by Edward Yang

Hi everyone, We have discussed the design proposal of supporting secure Flash in tf-m framework via this mailing list before,now the implementation code of this external trusted secure storage partition has been uploaded to tf-m-extras repo for review： https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953 And the binary component of this patch has also been uploaded to tf-binaries repo： https://review.trustedfirmware.org/c/tf-binaries/+/14954 For easy understanding please refer to this document first: https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953/1/partitions/… Looking forward to your comments and suggestions. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

3 years, 1 month

1
0
0 0

Start of TF-M v1.6.0 release process

by Anton Komlev

Hello, The branch release/1.6.x<https://git.trustedfirmware.org/TF-M%2Ftrusted-firmware-m.git/log/?h=refs%2…> has been created, indicating the project feature's freeze and beginning the release process. Expecting to place RC1 tag asap, after successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

3 years, 1 month

1
4
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi All, TF-M Open CI is back to normal now. Please feel free to use it. Thanks, Xinyu From: Xinyu Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 18, 2022 12:06 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M Open CI Down Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 2 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 2 months

1
0
0 0

Technical Forum call - April 14 is CANCELLED

by Anton Komlev

Hi, The forum is cancelled because of the empty agenda and the assumption that many of us in the west time zone will have a long weekend this week. Thanks, Anton From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, April 6, 2022 12:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - April 14 Hi, The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 2 months

1
0
0 0

TF-M Isolation 3

by Doka.Dokanov-Dobrovolskyi＠infineon.com

Hello! My name is Oleg. I'm working on TF-M Isolation Level 3 testing and I need to develop test cases list for it. Could you be so kind to provide me the test cases list? May be you know where I can find it by myself? Also I have test cases list for Isolation Leve 2. Am I right that it can be reused for Isolation Level 3 with some changes? I will be very appreciate for any help. Thank you so much, Oleg Dokanov

3 years, 2 months

2
1
0 0

Technical Forum call - April 14

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 14, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 2 months

2
2
0 0

Mbed TLS GitHub migration

by Dave Rodgman

Hi all, Please be advised that the Mbed TLS GitHub migration is complete. The new home for Mbed TLS is: https://github.com/Mbed-TLS We recommend updating your project, checkouts, etc to point at the new repository, but it's not urgent as everything will continue to work for some time via automatic redirection. Also please note that our project boards, which we use for planning upcoming work via epics, and tracking current activity, have moved. They are now available here: Epics board: https://github.com/orgs/Mbed-TLS/projects/1 Current activity: https://github.com/orgs/Mbed-TLS/projects/2 Thanks Dave Rodgman On 22/03/2022, 14:52, "Dave Rodgman via Mbed-tls-announce" <mbed-tls-announce(a)lists.trustedfirmware.org> wrote: Hi all, Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected. This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete. All of the Mbed TLS repositories will migrate to this new organisation, i.e.: mbedtls mbedtls-docs mbedtls-test Thanks Dave Rodgman -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

3 years, 2 months

1
0
0 0

Technical Forum call - March 31

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 31, 7:00-8:00 UTC (East time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 2 months

3
3
0 0

TF-M on GitHub opinions collection

by Anton Komlev

Hello, Quite some time ago there was a proposal to move TF-M into GitHub. The main motivation is: more convenient review process, the Wiki for knowledge sharing and issue tracking facility. This idea had been discussed multiple times in TSC. The following options were considered: 1. Hybrid: Add TF-M on GitHub with 2 ways synchronization between GitHub and existing Git/Gerrit 2. GitHub only: Move to GitHub completely and drop Gerrit. 3. Mirror: Create a read-only mirror on GitHub. TF-M review process stays in Gerrit but Wiki and issue tracking are on GitHub. 4. Nothing: Stay on Gerrit as good enough solution. The options are ordered by complexity and cost each has pros and cons. The Mirror option (3) seeing as the best compromise and practically affordable in a short time. Please share your opinion and comments on the topic with any dependencies or specific requirements to be considered. Thanks, Anton

3 years, 2 months

8
17
0 0

TF-M Profile Small supports SFN model

by David Hu

Hi all, I'd like to ask for your help to review the patch which enables SFN model in TF-M Profile Small. SFN model is defined in FF-M v1.1 spec. With this patch, Profile Small still enables Library model by default and users can select SFN model instead via build command. Patch: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14500 TF-M Profile Small document update: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14501 Any comment or suggestion is welcome. Best regards, Hu Ziji

3 years, 3 months

1
0
0 0

TrustedFirmware Code of Conduct

by Don Harbin

Hi All, Please find the link to the TrustedFirmware Community Code of Conduct here: https://developer.trustedfirmware.org/w/collaboration/community_guidelines/… Trusted Firmware has a very diverse and global developer community. It is important that we adhere to the code of conduct in all our interactions. For some of you all this may be new and for others just a gentle reminder. In either case, if you have any questions, please feel free to reach out to me directly. And thanks to you all for your contributions to the TrustedFirmware community! Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

3 years, 3 months

1
0
0 0

Technical Forum call - March 17

by Arnold Gabriel Benedict

Hi, I would like to present our study on RPC Test Framework for TF-M along with a demo in our next technical forum on 17th March. Thanks, Arnold

3 years, 3 months

2
1
0 0

Secure Partition interrupt signal processing

by Andersson, Joakim

Hi. I've been working on making an example on how an application can use the secure interrupts in a secure partition in TF-M. During this I've encountered an issue where the secure partition will not be scheduled to process the secure interrupt signal in certain conditions. I've compared it to the current SLIH and FLIH test cases to my observed behaviour and I could see that they did not have this problem. I've created a test-case that triggers the problem [0]. In the mailing list I can see that this was actually discussed recently [1] The summary is that secure partitions will not be scheduled to process a secure interrupt signal when the interrupt is interrupting the NSPE. I could not find that this was documented anyway, but maybe I have overlooked. In any case I find this behaviour very unexpected and I would like to know if this is indeed a design decision and the behaviour has to be this way? If I wanted to do some processing in the secure partition context it would now mean that I have to get the NSPE to trigger this through a secure partition call. This seems like a limitation to me . I'd like to know what would be the issue with scheduling the partition once it now has the signal asserted. I've done a quick test with scheduling the partition at this point with [2] and this now works as I expect it to. I'd be happy to follow up with submitting a change to schedule the partition as done in [2] if that is an acceptable solution. [0] https://github.com/joerchan/tf-m-tests/commit/d9f0a3a7653b594d0fa797d9e0bca… [1] https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.… [2] https://github.com/joerchan/sdk-trusted-firmware-m/commit/e5512c6e8b2bad95c…

3 years, 3 months

2
1
0 0

MCUboot upgraded to v1.9.0 in TF-M

by Sherry Zhang

Hi, Just a reminder that the MCUboot version has been upgraded to v1.9.0<https://github.com/mcu-tools/mcuboot/releases/tag/v1.9.0> in TF-M. If you are using the local MCUboot repo, then you need to update it to that version to avoid build error. Regards, Sherry Zhang

3 years, 3 months

1
0
0 0

Technical Forum call - March 17

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 17, 15:00-16:00 UTC (West time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 3 months

1
0
0 0

The new design proposal guideline now take effect

by David Hu

Hi all, The new and simplified TF-M design proposal guideline is approved: https://tf-m-user-guide.trustedfirmware.org/docs/contributing/tfm_design_pr…. Please feel free to submit your topics to mailing list or tech forum! Formal design documents are NOT required anymore. Best regards, Hu Ziji

3 years, 3 months

1
0
0 0

TF-M release v1.6,0 date change to April 28

by Anton Komlev

Hello, TF-M release v1.6.0 will be shifted from April 15 to April 28. The main reason is Easter holiday and expected lack of availability from community and platform owners around that date. Feature freeze will be moved to April 6th when the release branch will be created. Please update your plans accordingly. Please let me know if this change make difficulty for you and better date is possible. Thanks, Anton

3 years, 3 months

1
0
0 0

Simplify TFM_PLATFORM in build system

by Jianliang Shen

Hi all, I want to simplify the flag TFM_PLATFORM in build system. TF-M now already supports two different ways to choose specific platform, for example AN521: - Absolute path: '<tf-m path>/platform/ext/target/arm/mps2/an521' - Relative path: 'arm/mps2/an21' Recently I have uploaded a [tf-m patch]<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14260> to support platform name: - Platform name: 'an521' I think it will be more convenient for developers to use: - Users don't need to remember and type the absolute or relative path, only target platform name is enough. - If the structure of certain platform is changed, the default build command of TFM_PLATFORM is same. I'd be very grateful if you can give any suggestion or enhancement for me. Thanks. Best Regards Jianliang Shen

3 years, 3 months

1
0
0 0

TF-M design documents about spm

by zhilei.wang

Dear All, I view the tf-m source code for the first time, and many of the code details can not be make clear. So .., where may I find the design documents of spm, for example: trusted-firmware-m-TF-Mv1.5.0\secure_fw\spm\cmsis_func and cmsis_psa software modules. Best Regards Wang Zhilei | Software Beken Corporation ---------------------------------------------------------------------------- ---------------------------------------------------------

3 years, 3 months

3
2
0 0

Technical Forum call - March 3

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 3, 7:00-8:00 UTC (Asian time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 3 months

2
2
0 0

TF-M covertly results and configs to align our coverity environment to TF-M project CI

by Kostiantyn.Tkachov＠infineon.com

Hi colleagues! Could we get a list of MISRA/CERT-C violations that were found by tf-m Coverity CI, as example from https://ci.trustedfirmware.org/job/tf-m-coverity/lastSuccessfulBuild/ Also (if it possible), could you provide Coverity configs to help align this tool setup on our side to CI and to check all changes before any pool requests? Best regards, Kostiantyn Tkachov Cypress Semiconductor Ukraine Firmware Security

3 years, 3 months

2
1
0 0

Problem compiling Trusted Firmware M in Linux for PSOC64

by AntonioJavier.CabreraGutierrez＠infineon.com

Hello, I am writing to you asking help because we are having problems when I try to compile the Trusted Firmware M from source code. I downloaded the code from the official repository: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git I moved to the last TAG: TF-Mv1.5.0 I am following this tutorial for PSOC64 platform https://tf-m-user-guide.trustedfirmware.org/platform/ext/target/cypress/pso… When I execute the first cmake command indicating the platform and the toolchain everything works well: cmake -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake .. The problems appears when I build the code using the second cmake command: cmake --build cmake_build -- -j I got this output [cid:image003.jpg@01D82A77.95B43640] /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_verify': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:145:5: error: conversion to non-scalar type requested 145 | verification_key_psa = (psa_key_handle_t)verification_key.k.key_handle; | ^~~~~~~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_pub_key_sign': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:194:5: error: conversion to non-scalar type requested 194 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c: In function 't_cose_crypto_sig_size': /home/admin/Escritorio/trusted-firmware-m/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.c:245:5: error: conversion to non-scalar type requested 245 | signing_key_psa = (psa_key_handle_t)signing_key.k.key_handle; | ^~~~~~~~~~~~~~~ secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/build.make:425: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o' failed make[2]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/__/__/__/lib/ext/t_cose/crypto_adapters/t_cose_psa_crypto.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CMakeFiles/Makefile2:1347: recipe for target 'secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all' failed make[1]: *** [secure_fw/partitions/internal_trusted_storage/CMakeFiles/tfm_psa_rot_partition_its.dir/all] Error 2 Makefile:135: recipe for target 'all' failed make: *** [all] Error 2 There are the version of the software that are using: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release) cmake version 3.23.0-rc2 It seems strange to me that there are compilation errors in the source code, that's why I am writing this mail, in case there is a bug in the code. Best regards. Antonio Javier Cabrera Gutierrez Infineon Technologies AG PhD Candidate R&D Engineer IFAG BEX RDE RDF ISS Office: +49 89 234 36403 Mobile: +49 151 181 34322 AntonioJavier.CabreraGutierrez(a)infineon.com<mailto:AntonioJavier.CabreraGutierrez@infineon.com> Am Campeon 1-15 85579 Neubiberg Germany www.infineon.com<http://www.infineon.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. Infineon Technologies AG Chairman of the Supervisory Board: Dr. Wolfgang Eder Management Board: Dr. Reinhard Ploss (CEO), Dr. Helmut Gassel, Jochen Hanebeck, Dr. Sven Schneider Registered Office: Neubiberg Commercial Register: München HRB 126492 This e-mail and any attachments are confidential. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. Any unauthorized use or disclosure may be unlawful. If you have received this e-mail by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it.

3 years, 3 months

3
2
0 0

Locking of PRIS bit in AIRCR register

by JAYLES Romain

Hi all, We are currently testing the tfm-m implementation on a STMicroelectronic chip: stm32u5 board. This stm32u5 has a special register: SYSCFG_CSLOCKR (see https://www.st.com/resource/en/reference_manual/rm0456-stm32u575585-armbase…). This register allows to lock the PRIS bit of the AIRCR register from further modification. The issue here is that, in the ST implementation, thanks to this SYSCFG_CSLOCKR, the PRIS bit of the AIRCR is locked at boot (Reset_Handler in file startup_stm32u5xx_s.c). Resulting in the function tfm_arch_set_secure_exception_priorities() not being able to set the PRIS bit of the AIRCR. This situation lead to big issues at runtime as interrupt priority of NSPE are able to pre-empt interrupt of SPE. Disabling the locking of PRIS bit solve our problem but currently we don't see a clean way to integrate chip specific security features (something like callback/tfm_hal_ ) after the function tfm_arch_set_secure_exception_priorities() has been called. What would be the best way to fix the current issue which could also arise on other platform ? Regards, Romain

3 years, 3 months

3
4
0 0

Please review a new design proposal guideline

by David Hu

Hi all, As part of the documentation improvements, a new design proposal guideline [1] is proposed to replace and simplify the current process. The basic idea is to encourage developers to share their design via mailing list and tech forum, without a well-formatted design document. If developers prefer a document for a new feature, please provide an integration guide/user manual instead. Please check the details in the patch below. [1] https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/14104 The rendered html version: https://ci-builds.trustedfirmware.org/static-files/KTOoRMhB4VsgNQFkdMgWZcZG… Best regards, Hu Ziji

3 years, 3 months

1
0
0 0

Issues with psa_wait() when waiting for interrupts and IPC function calls.

by Martin Gunnarsson

Hello, I am trying to write an Application RoT for a research project I am a part of. I have run into an issue that I have been unable to solve independently. My problem is the unexpected behavior of psa_wait() when using signal masks. I have two signals, TFM_TIMER1_IRQ_SIGNAL and TFM_SECURE_FUNCTION_SIGNAL. The TIMER1_IRQ signal is triggered by an FLIH interrupt handler that returns TFM_FLIH_SIGNAL. The interrupt is triggered every 1 second by TIMER1. The TFM_SECURE_FUNCTION_SIGNAL is triggered by a periodic function call from the NSPE (a Zephyr thread) and is called every 10 seconds. Observed result: If PSA_WAIT_ANY is used as a signal mask, the TIMER0_IRQ_SIGNAL will only be received when TFM_SECURE_FUNCTION_SIGNAL is received, ergo, every 10 s. Thus any stage 2 handling of an interrupt would be missed. If TFM_TIMER1_IRQ_SIGNAL is used as a signal mask, the signal will be received every 1 s as expected. The TFM_SECURE_FUNCTION_SIGNAL will never be received, as can be expected in the NSPEtoo. I have tried a "hybrid approach" where I call psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK) /* handle signals .... */ and then psa_wait(TFM_SECURE_FUNCTION_SIGNAL, PSA_POLL). The stage 2 IRS is called, and the secure function is also called. But not with the regularity that I would like. Am I missing something obvious? I have read the Secure Interrupt Integration Guide and carefully studied the SLIH and FLIH test services for the TF-M regression tests. Have I forgotten to reset a signal somewhere? Does the interrupt not preempt the NSPE? I would be immensely grateful for any or all responses. If you need more information, please let me know. Best wishes, Martin Gunnarsson PhD Student RISE Research Institutes of Sweden & Lund University Complete code of my Application RoT: #include <stdbool.h> #include <stdint.h> #include <stddef.h> #include "tfm_api.h" #include "tfm_secure_api.h" #include "psa/service.h" #include "tfm_sp_log.h" #include "psa_manifest/pid.h" #include "psa_manifest/tfm_secure_partition.h" #include <hal/nrf_gpio.h> #include <hal/nrf_timer.h> #include <helpers/nrfx_reset_reason.h> #include <nrf_board.h> #include <region_defs.h> #define TIMER_RELOAD_VALUE (1*1024*1024) static volatile uint32_t interrupt_ctr = 0; static volatile uint32_t function_ctr = 0; static void timer_init(NRF_TIMER_Type * TIMER) { nrf_timer_mode_set(TIMER, NRF_TIMER_MODE_TIMER); nrf_timer_bit_width_set(TIMER, NRF_TIMER_BIT_WIDTH_32); nrf_timer_frequency_set(TIMER, NRF_TIMER_FREQ_1MHz); nrf_timer_cc_set(TIMER, NRF_TIMER_CC_CHANNEL0, TIMER_RELOAD_VALUE); /* Clear the timer once event is generated. */ nrf_timer_shorts_enable(TIMER, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK); } static void timer_stop(NRF_TIMER_Type * TIMER) { nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_STOP); nrf_timer_int_disable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } static void timer_start(NRF_TIMER_Type * TIMER) { timer_stop(TIMER); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_CLEAR); nrf_timer_int_enable(TIMER, NRF_TIMER_INT_COMPARE0_MASK); nrf_timer_task_trigger(TIMER, NRF_TIMER_TASK_START); } static void timer_event_clear(NRF_TIMER_Type *TIMER) { nrf_timer_event_clear(TIMER, NRF_TIMER_EVENT_COMPARE0); } void tfm_secure_controller_secure_timer_start(void) { timer_init(NRF_TIMER1); timer_start(NRF_TIMER1); } void tfm_secure_controller_secure_timer_clear_intr(void) { timer_event_clear(NRF_TIMER1); } psa_flih_result_t tfm_timer1_irq_flih(void) { tfm_secure_controller_secure_timer_clear_intr(); interrupt_ctr++; return PSA_FLIH_SIGNAL; } static psa_status_t tfm_sp_secure_function_ipc(psa_msg_t *msg) { function_ctr++; LOG_INFFMT("Secure function called %u times, interrupt ctr: %u\n", function_ctr, interrupt_ctr ); return PSA_SUCCESS; } void tfm_sp_secure_function(psa_msg_t *msg) { psa_status_t status; status = tfm_sp_secure_function_ipc(msg); psa_reply(msg->handle, status); } void tfm_sp_entry(void) { LOG_INFFMT("Secure Partition: Init\n"); tfm_secure_controller_secure_timer_start(); psa_irq_enable(TFM_TIMER1_IRQ_SIGNAL); psa_signal_t signals = 0; uint32_t ctr = 0; while (1) { signals = psa_wait(TFM_TIMER1_IRQ_SIGNAL, PSA_BLOCK); if ( (signals & TFM_TIMER1_IRQ_SIGNAL) == TFM_TIMER1_IRQ_SIGNAL) { ctr++; LOG_INFFMT("FLIH stage 2 %u\n", interrupt_ctr); psa_reset_signal(TFM_TIMER1_IRQ_SIGNAL); } if ( ctr % 10 == 0 ) { signals = psa_wait(PSA_WAIT_ANY, PSA_POLL); if ( (signals & TFM_SECURE_FUNCTION_SIGNAL) == TFM_SECURE_FUNCTION_SIGNAL) { psa_msg_t msg; psa_get(signals, &msg); tfm_sp_secure_function(&msg); } } } }

3 years, 3 months

2
8
0 0

New API tfm_hal_system_halt()

by Bøe, Sebastian

Hi, in the effort to ease debugging by supporting a choice between halting and rebooting we are introducing a new HAL API: void tfm_hal_system_halt(void) which by default (weak) does: __disable_irq(); while(1) { __WFE(); } CPUs cannot halt. But they can sleep until they are awoken in a loop, which is pretty close. tfm_hal_system_halt() is, when configured so, used by tfm_core_panic() which is why we disable irqs to stop all threads of execution, not just the thread that is executing. Currently it is proposed that tfm_core_panic() halts when TFM_HALT_ON_CORE_PANIC is ON and otherwise reboots. TFM_HALT_ON_CORE_PANIC is default ON if and only if Debug mode is enabled. Any feedback to these changes are welcome, and if any platform needs to halt in a different manner then a contribution would be welcome as well. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

3 years, 3 months

1
0
0 0

TF-M regression test refinements

by Jianliang Shen

Hi, all I'd like to share two new refinements in TF-M test repo to you. l The struct variable test_result_t has been removed from the definition of struct variable test_t. It is unnecessary to set an initial value of test result for each case. With this change, the binary size will be reduced. Please see [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13822/4> for more details. l The flag TEST_SKIPPED has been added into enum variable test_status_t, works with TEST_PASSED and TEST_FAILED. TEST_SKIPPED indicates that the test case is skipped in runtime when the test environment is unavailable. Please ee [test patch]<https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/13826/5> for more details. Hope these two changes can help your work in the future. Please let me know if anything can be improved. Thanks! Best Regards Jianliang Shen

3 years, 4 months

1
0
0 0

FF PSA API overhead

by Bøe, Sebastian

Hi, the performance improvement presentation[0] reports a FF PSA API overhead of 20 000 CPU cycles for the psa_call. Which is 300 us for a 64MHz CPU. This is quite a lot of instructions and I am concerned about whether real world embedded application's will have time to call these secure services. I'm interested in isolation level 2. I understand that it is not possible to have isolation level 2 with library mode. But what about SFN mode, could that eventually support isolation level 2? If not, what is the current status of optimizing the service call overhead for IPC. Is it considered to be as optimized as it can be or is there still hope for optimizing further? [0] https://www.trustedfirmware.org/docs/tf-m_forum_20211209-TF-M_Performance-I…

3 years, 4 months

2
1
0 0

Technical Forum call - Feb 17

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, February 17, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 4 months

2
2
0 0

[FYI] Tiny update in level 3 ld/sct files

by Ken Liu

Hi, We got a tiny update merged in level 3 ld/sct files to support partition runtime: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13925 Platforms with level 3 support please have a test and report issue here if spotted. We have internally tested MPS2 and MUSCA_B1. Thanks. /Ken

3 years, 4 months

1
0
0 0

halting or rebooting on faults

by Bøe, Sebastian

Hi, it seems we could try to be more consistent with fault handling. The current default behaviour is: Error code returned from an SPE function? Reboot. MemFault/HardFault/SecureFault in the SPE? Halt. Null-pointer dereference from the NSPE? (results in a secure fault for cortex-m) Halt. Should we perhaps consistently halt or consistently reboot for these three cases and allow this to be configurable? It is not clear to me why an error returned from a function results in a reboot, whereas a Hardfault does not. They both indicate a fault in the SPE. At the very least the behaviour should be configurable, which this PR is a step towards: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13839

3 years, 4 months

5
4
0 0

Security vulnerability notice - Firmware Update psa_fwu_write service vulnerability

by Sherry Zhang

Hi all, This email is a notification of a new security vulnerability reported to TF-M. In TF-M version between 3e7129f<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=3e71…> and 921d0ea<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=921d…>, the caller of ``psa_fwu_write()`` from SPE or NSPE can overwrite the stack memory outside of the local buffer in Firmware Update partition in IPC model. Please check the details in the security advisory doc<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13873/5/docs…>. The advisory has been merged in master branch today. The fix<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/?id=78f7…> has been merged into master branch before TF-Mv1.5.0. Regards, Sherry Zhang

3 years, 4 months

1
0
0 0

Dual core broken

by Chris.Brand＠infineon.com

Commit 27f9a49508547320c50056a52a372674c27771eb seems to have missed changing ns_agent_mailbox, breaking dual core. I'd send a patch, but I's not immediately obvious what it should look like... Seems like a good change, but inadequately reviewed? 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.

3 years, 4 months

2
1
0 0

Why ARM_FLASH_STATUS is volatile in flash driver?

by Roman Mazurak

Hi all, Why ARM_FLASH_STATUS was declared volatile in https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/commit/platform… commit ? I believe it's much better to declare volatile variable when there is such need instead of forcing all variables to become volatile through typedef. Thanks, Roman.

3 years, 4 months

2
2
0 0

[CANCELLED] Technical Forum call - Feb 3

by Anton Komlev

Hi, Let's cancel the forum tomorrow due to the empty agenda and the holiday time in Asia. Best regards, Anton From: Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, January 27, 2022 4:36 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Feb 3 Hi, The next Technical Forum is planned on Thursday, Feb 3, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. This slot is in Chinese New Year celebration period so we can expect fewer participants from Asia. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 4 months

1
0
0 0

Custom implementation of of tfm_hal_system_reset

by Bohdan.Hunko＠infineon.com

Hi everyone, I have a few questions related to TF-M code: 1. Default implementation of tfm_hal_system_reset(void) from platform/ext/common/tfm_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> just calls NVIC_SystemReset(), but some ARM platform, take musca_b1 for example, reimplement it (platform/ext/target/arm/musca_b1/sse_200/tfm_hal_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> ). Custom implementations tend to also disable and clean IRQ and call mpc_revert_non_secure_to_secure_cfg(); Is there any benefits of doing that??? If so then what those benefits are? 1. tfm_core_panic() (secure_fw/spm/ffm/utilities.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) when TFM_FIH_PROFILE_ON is defined calls fih_delay() and tfm_hal_system_reset() twice. Is this done to ensure that tfm_hal_system_reset() will be called (even if first one was skipped there is second one)? And if so, can a comment be added there to highlight that intention? 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>

3 years, 4 months

3
2
0 0

Technical Forum call - Feb 3

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Feb 3, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. This slot is in Chinese New Year celebration period so we can expect fewer participants from Asia. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 4 months

1
0
0 0

Please Use Test Version Specified in TF-M CMake Configs

by Xinyu Zhang

Hi All, Please do use the tf-m-tests version specified in TF-M CMake configs (TFM_TEST_REPO_VERSION in trusted-firmware-m/lib/ext/tf-m-tests/repo_config_default.cmake), otherwise there might be some unexpected build errors. Please let us know if there is any problem. Thanks, Xinyu

3 years, 4 months

1
0
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi All, TF-M Open CI is back to normal. Please feel free to use. Thanks, Xinyu From: Xinyu Zhang Sent: Monday, January 17, 2022 4:05 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: TF-M Open CI Not Stable Right Now Hi All, Sorry to inform you that TF-M Open CI is not stable right now. Jobs are likely to come into unexpected failure. I'll keep following up with the latest information. Sorry for any inconvenience! Thanks, Xinyu

3 years, 4 months

1
0
0 0

unsubscribe

by st9hack＠yahoo.com

unsubscribe

3 years, 5 months

1
0
0 0

Technical Forum call - Jan 20

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, January 20, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 5 months

2
2
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (MST) (tf-m@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been changed. Title: TF-M Tech forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq When: Every 4 weeks from 8am to 9am on Thursday Mountain Standard Time - Phoenix Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com * abdelmalek.omar1(a)gmail.com * kevin.townsend(a)linaro.org * seth(a)nxmlabs.com * leonardo.sandoval(a)linaro.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 5 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 8am to 9am on Thursday (MST) (tf-m@lists.trustedfirmware.org)

by don.harbin＠linaro.org

This event has been changed. Title: TF-M Tech forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq When: Every 4 weeks from 8am to 9am on Thursday Mountain Standard Time - Phoenix Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com * abdelmalek.omar1(a)gmail.com * kevin.townsend(a)linaro.org * seth(a)nxmlabs.com * leonardo.sandoval(a)linaro.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 years, 5 months

1
0
0 0

TF-M Open CI Not Stable Right Now

by Xinyu Zhang

Hi All, Sorry to inform you that TF-M Open CI is not stable right now. Jobs are likely to come into unexpected failure. I'll keep following up with the latest information. Sorry for any inconvenience! Thanks, Xinyu

3 years, 5 months

1
0
0 0

Remove use of ER_INITIAL_PSP

by Mingyang Sun

Hi, ER_INITIAL_PSP section was used as the Trustzone NS Agent partition stack in IPC model. Since Trustzone NS Agent partition has changed to use private variables as its stack, ER_INITIAL_PSP related definitions and references can be removed. Change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13186 This change involves all the platforms for IPC model, it removes: * Definition of ER_INITIAL_PSP section in the linker script * Reference of ER_INITIAL_PSP for isolation configuration in platform HALs This can simplify the linker script a bit. This patch is going to be put there for a while as there are holidays, but please do review it when you see this mail. Plan to merge it before end of Jan, as soon as all concerns get addressed (if there are). Regards, Mingyang

3 years, 5 months

2
2
0 0

Code size analyze tool for TF-M further optimization

by Jianliang Shen

Hi all, I'd like to introduce a code size analyse tool to you. The tool is developed to help optimize TF-M code size by gathering the data from map file and output friendly. These python scripts can - Get a database to implement data tables from ARMCLANG or GNUARM map file. - Supply an UI for developers to scan sorted information of sections, libraries, object files, functions and data. - Help analyse the biggest or smallest targets in certain image. It can also help search functions or data to locate their address and detail information. - Diff two databases to see the code size increment or decrement between two different build results. The patch is: [tf-m-tools]<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/12665>, it also contains the document for users. Hope this tool can help you measure code size in the daily work. Please let me know if anything can be improved. I'd like to merge this tool this Friday if no critical comment. Best Regards Jianliang Shen

3 years, 5 months

1
1
0 0

Asking for patch review of aligning flash driver to CMSIS Flash APIs

by Sherry Zhang

Hi, Currently, there is a known misalignment with the current CMSIS Flash interface in TF-M as described in TF-M doc<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/integ…>. I created this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/13295/> to eliminate the misalignment. As it impacts all the platforms, may I ask for review on this patch? This patch has been verified by staging nightly CI. Thanks! Regards, Sherry Zhang

3 years, 5 months

1
1
0 0

Re: Power management and TFM

by Suresh.Marisetty＠infineon.com

Here is what I could find on Zephyr: https://docs.zephyrproject.org/1.14.1/reference/power_management/index.html Any thoughts from anybody on this topic. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Thursday, January 13, 2022 2:19 AM To: Joseph Yiu <Joseph.Yiu(a)arm.com>; Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com> Subject: RE: Power management and TFM Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Suresh, As you noted, the power management topic is not covered by TF-M, leaving it for a platform or project level handling. Would you like to discuss the topic on TF-M Tech Forum and check what community thinks about it? Best regards, Anton From: Joseph Yiu <Joseph.Yiu(a)arm.com<mailto:Joseph.Yiu@arm.com>> Sent: Wednesday, January 12, 2022 8:52 PM To: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Subject: RE: Power management and TFM Hi Suresh, > Power management does have an impact on security flows and how it is done. Agree. > Not sure if there is a standardized framework and application note on how it can be done on Corte-M with or without Secure Enclave model Unfortunately there is no standardization of power management interface for Cortex-M systems today. And given that the low power implementation varies between different vendors significantly, trying to define a power control interface is going to be very challenging. By the way, I noticed you reply to me only. Is that intentional or would you want to have this conversation on the email list? Regards, Joseph From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>> Sent: 12 January 2022 18:58 To: Joseph Yiu <Joseph.Yiu(a)arm.com<mailto:Joseph.Yiu@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Power management and TFM HI Anton and Joseph, Power management does have an impact on security flows and how it is done. This is a town down architecture/implementation starting with NSPE and down with expected behavior of SPE (secure boot, TFM context management, etc.), cold boot, warm boot, deep-sleep, hibernate and active modes. On the Cortex-A, there is PSCI framework couple with ACPI. Not sure if there is a standardized framework and application note on how it can be done on Corte-M with or without Secure Enclave model. thanks Suresh Marisetty Infineon Semiconductor Corporation From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Joseph Yiu via TF-M Sent: Monday, December 20, 2021 8:04 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Power management and TFM Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>. Hi Suresh, Anton, This is an interesting topic :-) Armv8-M processors has some power management registers that can be restricted to Secure world access only. System Control Register (SCR) - Bit 2 SLEEPDEEP - 0 = Normal Sleep, 1 = Deep Sleep (this can also enable WIC feature). Access permission depends on SLEEPDEEPS. - Bit 3 SLEEPDEEPS - 0 - NS privileged world can r/w to SLEEPDEEP, 1 - SLEEPDEEP is RAZ/WI to NS privileged world (This is applicable to Cortex-M23, Cortex-M33, Cortex-M35P, Cortex-M55) Cortex-M55 also has Implementation defined power model control registers (CPDLPSTATE, DPDLPSTATE) https://developer.arm.com/documentation/101273/0101/Cortex-M55-Processor-le… If TrustZone is used (AIRCR.BFHFNMINS is 0), then these registers are Secure privileged access only. So definitely Secure firmware should provide some APIs for Non-secure software for changing the power control settings. However, I would expect that power control APIs would likely to be at a higher level which also manage other system level power control functions (which, as Anton said, device specific). In such case having APIs for modifying SLEEPDEEP and power model control registers is not helpful (or might even end up with confusions - e.g. if a SW developer trying to use both low level and high level APIs at the same time). Given that a Secure firmware can setup SLEEPDEEPS easily if it wants to allow/disallow access to SLEEPDEEP control, having an API for this might be overkill. Access to Cortex-M55's power model control registers is more tricky. Would an 'optional' reference API for updating power model control registers (CPDLPSTATE, DPDLPSTATE) be considered? Regards, Joseph From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 20 December 2021 12:32 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Power management and TFM Hi Suresh, The power management is out of scope of TF-M core or any PSA service. Such functionality is HW platform specific and may vary depending on HW or SW adaptation capabilities. If you concern about a specific use case, where TF-M support is expected - let's discuss it here. Hope that helps, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, December 17, 2021 8:11 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Power management and TFM Hi, Wondering if anybody can throw some light on any ongoing efforts on power management on a system with TFM (deep sleep, etc). thanks Suresh Marisetty Infineon Semiconductor Corporation CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

3 years, 5 months

1
0
0 0

FPU register (D8~D15) corrupted in library mode

by Eason Lai (賴易聖)

Hello TFM owners, I would like to report an issue for ARMv8-MAIN in TFM. From GCC9, it may use FPU registers (S16~S31) to backup general purpose registers for better performance. However, TFM’s library mode is not backup and restore FPU registers (S16~S31) base on EXC_RETURN.FType bit in tfm_core_sfn_request. (Reference for LR.FType https://developer.arm.com/documentation/100235/0004/the-cortex-m33-processo… ) This may causes FPU registers (S16~S31) to be corrupted in tfm_core_sfn_request, if interrupt happens between two SVC call. Here is an example to reproduce the issue: 1. Task A uses FPU S16 register to backup GPR R0 2. Task A calls psa_import_key() API 3. After the instruction “SVC %[SVC_REQ]” in tfm_core_sfn_request, the CONTROL.FPCA become “NOT active” 4. Enter FreeRTOS PendSV_Handler and schedule to others task. * Originally, this should backup S16 due to CONTROL.FPCA is active and EXC_RETURN.FType should be 0. * But, the EXC_RETURN.FType become 1 due to step3. So the S16 is not backup in stack and changed by others task. 1. Another task uses FPU S16 register (overwrite the value of S16 from Task A) 2. Enter FreeRTOS PendSV_Handler and schedule back to Task A 3. psa_import_key is finished and exit from TFM 4. Task A restore GPR R0 from FPU R16 5. Memory access violation in Task A due to incorrect value of GPR R0. Stacking FPU s16-s31 in tfm_core_sfn_request can fix this problem. Please check the blue instructions. Thank you. __attribute__((section("SFN"), naked)) int32_t tfm_core_sfn_request(const struct tfm_sfn_req_s *desc_ptr) { __ASM volatile( "PUSH {r4-r12, lr} \n" "MRS r4, control \n" /* Check FPCA in control register */ "TST r4, #0x04 \n" "IT NE \n" /* Stacking S16-S31, if CONTROL.FPCA = 1 */ "VSTMDBNE sp!, {s16-s31} \n" "PUSH {r4} \n" /* Backup CONTROL register */ "PUSH {r4} \n" /* For 8-bytes alignment to prevent xPSR.BIT9 = 1 */ "SVC %[SVC_REQ] \n" /* To remove upon instruction, xPSR.BIT9 should be masked to 0 in prepare_partition_iovec_ctx(…) */ "MOV r4, #0 \n" "MOV r5, r4 \n" "MOV r6, r4 \n" "MOV r7, r4 \n" "MOV r8, r4 \n" "MOV r9, r4 \n" "MOV r10, r4 \n" "MOV r11, r4 \n" "BLX lr \n" "SVC %[SVC_RET] \n" "POP {r4} \n" /* Restore CONTROL register */ "POP {r4} \n" "TST r4, #0x04 \n" /* Check FPCA in control register */ "IT NE \n" "VLDMIANE sp!, {s16-s31} \n" /* Restore S16-S31, if CONTROL.FPCA = 1 */ "POP {r4-r12, pc} \n" : : [SVC_REQ] "I" (TFM_SVC_SFN_REQUEST), [SVC_RET] "I" (TFM_SVC_SFN_RETURN) ); } Best regards!

3 years, 5 months

3
4
0 0

Re: Pending PR needs merging

by Anton Komlev

Hi Jamie, The change has been merged. Sorry for the possible inconveniences caused by end of the year holidays. Best regards, Anton From: Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Tuesday, January 11, 2022 4:03 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Pending PR needs merging Hi, Would it be possible to get this PR merged https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12686 due to a pending update for Zephyr? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, LLC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, LLC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, LLC.

3 years, 5 months

2
1
0 0

Pending PR needs merging

by Jamie Mccrae

Hi, Would it be possible to get this PR merged https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12686 due to a pending update for Zephyr? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, LLC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, LLC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, LLC.

3 years, 5 months

1
0
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi all, TF-M CI is back to normal. Please feel free to use it. 😊 BR, Xinyu From: Xinyu Zhang Sent: Monday, January 10, 2022 11:07 AM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: TF-M Open CI Fails to Run Tests Hi all, Sorry to inform you that TF-M Open CI is down for the time being – tests cannot be run. I’ll let you know as long as CI is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 5 months

1
0
0 0

TF-M Open CI Fails to Run Tests

by Xinyu Zhang

Hi all, Sorry to inform you that TF-M Open CI is down for the time being - tests cannot be run. I'll let you know as long as CI is back to normal. Apologize for any inconvenience! Thanks, Xinyu

3 years, 5 months

1
0
0 0

Mailbox mechanism changed into partition

by Ken Liu

Hi, Thank Chris made a couple of changes to move the mailbox mechanism from a kernel-coupled one into a partition-based one, which simplifies the programming model much. And mailbox-related platforms (musca-b1 secure enclave and corstone 1000) may get affected after merged, please mentioned platform owners take a try on these patches. Another solution is we can merge them and then fix the problems found. Will wait for one more week for the last patch (Patches no affecting platforms out of PSoC are merged already). I think checkout this one should bring all related changes into local: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12311 Feel free to comment, thanks. /Ken

3 years, 5 months

1
1
0 0

Technical Forum call - Jan 6

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, Jan 6, 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

3 years, 5 months

1
1
0 0

PSA headers difference

by Bohdan.Hunko＠infineon.com

Hi everyone, While taking a look into PSA header files from interface/include/psa/ folder I have found out that they are actually slightly different from PSA headers in build_folder/lib/ext/mbedcrypto-src/include/psa/ folder. Here is list of files that are different: * crypto.h * crypto_compat.h * crypto_extra.h * crypto_sizes.h * crypto_struct.h * crypto_types.h * crypto_values.h My expectation was that PSA interface (header files) should be the same in both folders. Maybe we should use only one version of those files (remove files from interface/include/psa/ and just use files from build_folder/lib/ext/mbedcrypto-src/include/psa/)? 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>

3 years, 5 months

2
1
0 0

Some broken builds

by Thomas Törnblom

Back after the holidays I have tested a few builds and I've noticed that a few builds fail a bunch of tests. Fails on all tool chains. Is this a known issue? psoc64, musca_s1 works. Musca_B1 (nxp lpcxpresso55s69 also fails: PS D:\Projects\tf-m6\trusted-firmware-m\armclang> cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_b1/sse_200 "-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBL2=ON ... Running Test Suite PSA internal trusted storage S interface tests (TFM_S_ITS_TEST_1XXX)... > Executing 'TFM_S_ITS_TEST_1001' Description: 'Set interface' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:32) TEST: TFM_S_ITS_TEST_1001 - FAILED! > Executing 'TFM_S_ITS_TEST_1002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:91) TEST: TFM_S_ITS_TEST_1002 - FAILED! > Executing 'TFM_S_ITS_TEST_1003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:115) TEST: TFM_S_ITS_TEST_1003 - FAILED! > Executing 'TFM_S_ITS_TEST_1004' Description: 'Set interface with write once UID' Set should not rewrite a write once UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:138) TEST: TFM_S_ITS_TEST_1004 - FAILED! > Executing 'TFM_S_ITS_TEST_1005' Description: 'Get interface with valid data' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:186) TEST: TFM_S_ITS_TEST_1005 - FAILED! > Executing 'TFM_S_ITS_TEST_1006' Description: 'Get interface with zero data length' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:293) TEST: TFM_S_ITS_TEST_1006 - FAILED! ... (lots more failed tests) ... *** Non-secure test suites summary *** Test suite 'PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)' has PASSED Test suite 'PSA internal trusted storage NS interface tests (TFM_NS_ITS_TEST_1XXX)' has FAILED Test suite 'Crypto non-secure interface test (TFM_NS_CRYPTO_TEST_1XXX)' has FAILED Test suite 'Platform Service Non-Secure interface tests(TFM_NS_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service non-secure interface tests(TFM_NS_ATTEST_TEST_1XXX)' has PASSED Test suite 'QCBOR regression test(TFM_NS_QCBOR_TEST_1XXX)' has PASSED Test suite 'T_COSE regression test(TFM_NS_T_COSE_TEST_1XXX)' has PASSED Test suite 'PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)' has PASSED Test suite 'Core non-secure positive tests (TFM_NS_CORE_TEST_1XXX)' has PASSED Test suite 'IPC non-secure interface test (TFM_NS_IPC_TEST_1XXX)' has PASSED Test suite 'TFM IRQ Test (TFM_IRQ_TEST_1xxx)' has PASSED *** End of Non-secure test suites *** -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

3 years, 5 months

2
6
0 0

Some broken builds

by Thomas Törnblom

Back after the holidays I have tested a few builds and I've noticed that a few builds fail a bunch of tests. Fails on all tool chains. Is this a known issue? psoc64, musca_s1 works. Musca_B1 (nxp lpcxpresso55s69 also fails: PS D:\Projects\tf-m6\trusted-firmware-m\armclang> cmake -GNinja -S .. -B . -DTFM_PLATFORM=arm/musca_b1/sse_200 "-DTFM_TOOLCHAIN_FILE=..\toolchain_ARMCLANG.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBL2=ON Musca B eflash Firmware Version 3.4 [INF] Starting bootloader [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [INF] Swap type: none [INF] Swap type: none CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 [INF] Bootloader chainload address offset: 0x20000 [INF] Jumping to the first image slot [WRN] This device was provisioned with dummy keys. This device is NOT SECURE [Sec Thread] Secure image initializing! TF-M FP mode: Software Booting TFM v1.5.0 #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_S_PS_TEST_1XXX)... > Executing 'TFM_S_PS_TEST_1001' Description: 'Set interface' TEST: TFM_S_PS_TEST_1001 - PASSED! > Executing 'TFM_S_PS_TEST_1002' Description: 'Set interface with create flags' TEST: TFM_S_PS_TEST_1002 - PASSED! > Executing 'TFM_S_PS_TEST_1003' Description: 'Set interface with NULL data pointer' TEST: TFM_S_PS_TEST_1003 - PASSED! > Executing 'TFM_S_PS_TEST_1004' Description: 'Set interface with invalid data length' TEST: TFM_S_PS_TEST_1004 - PASSED! > Executing 'TFM_S_PS_TEST_1005' Description: 'Set interface with write once UID' TEST: TFM_S_PS_TEST_1005 - PASSED! > Executing 'TFM_S_PS_TEST_1006' Description: 'Get interface with valid data' TEST: TFM_S_PS_TEST_1006 - PASSED! > Executing 'TFM_S_PS_TEST_1007' Description: 'Get interface with zero data length' TEST: TFM_S_PS_TEST_1007 - PASSED! > Executing 'TFM_S_PS_TEST_1008' Description: 'Get interface with invalid UIDs' TEST: TFM_S_PS_TEST_1008 - PASSED! > Executing 'TFM_S_PS_TEST_1009' Description: 'Get interface with invalid data lengths and offsets' TEST: TFM_S_PS_TEST_1009 - PASSED! > Executing 'TFM_S_PS_TEST_1010' Description: 'Get interface with NULL data pointer' TEST: TFM_S_PS_TEST_1010 - PASSED! > Executing 'TFM_S_PS_TEST_1011' Description: 'Get info interface with write once UID' TEST: TFM_S_PS_TEST_1011 - PASSED! > Executing 'TFM_S_PS_TEST_1012' Description: 'Get info interface with valid UID' TEST: TFM_S_PS_TEST_1012 - PASSED! > Executing 'TFM_S_PS_TEST_1013' Description: 'Get info interface with invalid UIDs' TEST: TFM_S_PS_TEST_1013 - PASSED! > Executing 'TFM_S_PS_TEST_1014' Description: 'Get info interface with NULL info pointer' TEST: TFM_S_PS_TEST_1014 - PASSED! > Executing 'TFM_S_PS_TEST_1015' Description: 'Remove interface with valid UID' TEST: TFM_S_PS_TEST_1015 - PASSED! > Executing 'TFM_S_PS_TEST_1016' Description: 'Remove interface with write once UID' TEST: TFM_S_PS_TEST_1016 - PASSED! > Executing 'TFM_S_PS_TEST_1017' Description: 'Remove interface with invalid UID' TEST: TFM_S_PS_TEST_1017 - PASSED! > Executing 'TFM_S_PS_TEST_1018' Description: 'Block compaction after remove' TEST: TFM_S_PS_TEST_1018 - PASSED! > Executing 'TFM_S_PS_TEST_1019' Description: 'Multiple partial gets' TEST: TFM_S_PS_TEST_1019 - PASSED! > Executing 'TFM_S_PS_TEST_1020' Description: 'Multiple sets to same UID from same thread' TEST: TFM_S_PS_TEST_1020 - PASSED! > Executing 'TFM_S_PS_TEST_1021' Description: 'Get support interface' TEST: TFM_S_PS_TEST_1021 - PASSED! > Executing 'TFM_S_PS_TEST_1022' Description: 'Set, get and remove interface with different asset sizes' TEST: TFM_S_PS_TEST_1022 - PASSED! TESTSUITE PASSED! Running Test Suite PS reliability tests (TFM_PS_TEST_3XXX)... > Executing 'TFM_S_PS_TEST_2001' Description: 'repetitive sets and gets in/from an asset' > Iteration 15 of 15 TEST: TFM_S_PS_TEST_2001 - PASSED! > Executing 'TFM_S_PS_TEST_2002' Description: 'repetitive sets, gets and removes' > Iteration 15 of 15 TEST: TFM_S_PS_TEST_2002 - PASSED! TESTSUITE PASSED! Running Test Suite PS rollback protection tests (TFM_S_PS_TEST_3XXX)... > Executing 'TFM_S_PS_TEST_3001' Description: 'Check PS area version when NV counters 1/2/3 have the same value' TEST: TFM_S_PS_TEST_3001 - PASSED! > Executing 'TFM_S_PS_TEST_3002' Description: 'Check PS area version when it is different from NV counters 1/2/3' TEST: TFM_S_PS_TEST_3002 - PASSED! > Executing 'TFM_S_PS_TEST_3003' Description: 'Check PS area version when NV counters 1 and 2 are equals, 3 is different, and PS area version match NV counters 1 and 2' TEST: TFM_S_PS_TEST_3003 - PASSED! > Executing 'TFM_S_PS_TEST_3004' Description: 'Check PS area version when NV counters 2 and 3 are equals, 1 is different and PS area version match NV counter 2 and 3' TEST: TFM_S_PS_TEST_3004 - PASSED! > Executing 'TFM_S_PS_TEST_3005' Description: 'Check PS area version when NV counters 2 and 3 are equals, 1 is different and PS area version match NV counter 1' TEST: TFM_S_PS_TEST_3005 - PASSED! > Executing 'TFM_S_PS_TEST_3006' Description: 'Check PS area version when NV counters 1, 2 and 3 have different values and PS area version match NV counter 1 value' TEST: TFM_S_PS_TEST_3006 - PASSED! > Executing 'TFM_S_PS_TEST_3007' Description: 'Check PS area version when NV counters 1, 2 and 3 have different values and PS area version match NV counter 2 value' TEST: TFM_S_PS_TEST_3007 - PASSED! > Executing 'TFM_S_PS_TEST_3008' Description: 'Check PS area version when NV counters 1, 2 and 3 have different values and PS area version match NV counter 3 value' TEST: TFM_S_PS_TEST_3008 - PASSED! > Executing 'TFM_S_PS_TEST_3009' Description: 'Check PS area version when NV counter 1 cannot be incremented' TEST: TFM_S_PS_TEST_3009 - PASSED! TESTSUITE PASSED! Running Test Suite PSA internal trusted storage S interface tests (TFM_S_ITS_TEST_1XXX)... > Executing 'TFM_S_ITS_TEST_1001' Description: 'Set interface' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:32) TEST: TFM_S_ITS_TEST_1001 - FAILED! > Executing 'TFM_S_ITS_TEST_1002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:91) TEST: TFM_S_ITS_TEST_1002 - FAILED! > Executing 'TFM_S_ITS_TEST_1003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:115) TEST: TFM_S_ITS_TEST_1003 - FAILED! > Executing 'TFM_S_ITS_TEST_1004' Description: 'Set interface with write once UID' Set should not rewrite a write once UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:138) TEST: TFM_S_ITS_TEST_1004 - FAILED! > Executing 'TFM_S_ITS_TEST_1005' Description: 'Get interface with valid data' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:186) TEST: TFM_S_ITS_TEST_1005 - FAILED! > Executing 'TFM_S_ITS_TEST_1006' Description: 'Get interface with zero data length' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:293) TEST: TFM_S_ITS_TEST_1006 - FAILED! > Executing 'TFM_S_ITS_TEST_1007' Description: 'Get interface with invalid UIDs' TEST: TFM_S_ITS_TEST_1007 - PASSED! > Executing 'TFM_S_ITS_TEST_1008' Description: 'Get interface with data lengths and offsets greater than UID length' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:426) TEST: TFM_S_ITS_TEST_1008 - FAILED! > Executing 'TFM_S_ITS_TEST_1009' Description: 'Get interface with NULL data pointer' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:541) TEST: TFM_S_ITS_TEST_1009 - FAILED! > Executing 'TFM_S_ITS_TEST_1010' Description: 'Get info interface with write once UID' Get info should not fail for write once UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:578) TEST: TFM_S_ITS_TEST_1010 - FAILED! > Executing 'TFM_S_ITS_TEST_1011' Description: 'Get info interface with valid UID' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:612) TEST: TFM_S_ITS_TEST_1011 - FAILED! > Executing 'TFM_S_ITS_TEST_1012' Description: 'Get info interface with invalid UIDs' TEST: TFM_S_ITS_TEST_1012 - PASSED! > Executing 'TFM_S_ITS_TEST_1013' Description: 'Remove interface with valid UID' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:708) TEST: TFM_S_ITS_TEST_1013 - FAILED! > Executing 'TFM_S_ITS_TEST_1014' Description: 'Remove interface with write once UID' Remove should not succeed with write once UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:751) TEST: TFM_S_ITS_TEST_1014 - FAILED! > Executing 'TFM_S_ITS_TEST_1015' Description: 'Remove interface with invalid UID' TEST: TFM_S_ITS_TEST_1015 - PASSED! > Executing 'TFM_S_ITS_TEST_1016' Description: 'Block compaction after remove' Set should not fail for UID 1 (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:790) TEST: TFM_S_ITS_TEST_1016 - FAILED! > Executing 'TFM_S_ITS_TEST_1017' Description: 'Multiple partial gets' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:860) TEST: TFM_S_ITS_TEST_1017 - FAILED! > Executing 'TFM_S_ITS_TEST_1018' Description: 'Multiple sets to same UID from same thread' First set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:911) TEST: TFM_S_ITS_TEST_1018 - FAILED! > Executing 'TFM_S_ITS_TEST_1019' Description: 'Set, get and remove interface with different asset sizes' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:995) TEST: TFM_S_ITS_TEST_1019 - FAILED! > Executing 'TFM_S_ITS_TEST_1020' Description: 'Set interface with invalid data length' TEST: TFM_S_ITS_TEST_1020 - PASSED! > Executing 'TFM_S_ITS_TEST_1021' Description: 'Get interface with invalid data lengths and offsets' TEST: TFM_S_ITS_TEST_1021 - PASSED! > Executing 'TFM_S_ITS_TEST_1022' Description: 'Get info interface with NULL info pointer' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/secure/psa_its_s_interface_testsuite.c:210) TEST: TFM_S_ITS_TEST_1022 - FAILED! > Executing 'TFM_S_ITS_TEST_1023' Description: 'Attempt to get a UID set by a different partition' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/secure/psa_its_s_interface_testsuite.c:253) TEST: TFM_S_ITS_TEST_1023 - FAILED! TESTSUITE FAILED! Number of failed tests: 18 of 23 Running Test Suite ITS reliability tests (TFM_ITS_TEST_2XXX)... > Executing 'TFM_S_ITS_TEST_2001' Description: 'repetitive sets and gets in/from an asset' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/secure/psa_its_s_reliability_testsuite.c:75) TEST: TFM_S_ITS_TEST_2001 - FAILED! > Executing 'TFM_S_ITS_TEST_2002' Description: 'repetitive sets, gets and removes' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/secure/psa_its_s_reliability_testsuite.c:133) TEST: TFM_S_ITS_TEST_2002 - FAILED! TESTSUITE FAILED! Number of failed tests: 2 of 2 Running Test Suite Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)... > Executing 'TFM_S_CRYPTO_TEST_1001' Description: 'Secure Key management interface' TEST: TFM_S_CRYPTO_TEST_1001 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1002' Description: 'Secure Symmetric encryption (AES-128-CBC) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_S_CRYPTO_TEST_1002 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1005' Description: 'Secure Symmetric encryption (AES-128-CTR) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_S_CRYPTO_TEST_1005 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1007' Description: 'Secure Symmetric encryption invalid cipher' TEST: TFM_S_CRYPTO_TEST_1007 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1008' Description: 'Secure Symmetric encryption invalid cipher (AES-152)' TEST: TFM_S_CRYPTO_TEST_1008 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1010' Description: 'Secure Unsupported Hash (SHA-1) interface' TEST: TFM_S_CRYPTO_TEST_1010 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1011' Description: 'Secure Hash (SHA-224) interface' TEST: TFM_S_CRYPTO_TEST_1011 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1012' Description: 'Secure Hash (SHA-256) interface' TEST: TFM_S_CRYPTO_TEST_1012 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1013' Description: 'Secure Hash (SHA-384) interface' TEST: TFM_S_CRYPTO_TEST_1013 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1014' Description: 'Secure Hash (SHA-512) interface' TEST: TFM_S_CRYPTO_TEST_1014 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1019' Description: 'Secure Unsupported HMAC (SHA-1) interface' TEST: TFM_S_CRYPTO_TEST_1019 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1020' Description: 'Secure HMAC (SHA-256) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_S_CRYPTO_TEST_1020 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1021' Description: 'Secure HMAC (SHA-384) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_S_CRYPTO_TEST_1021 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1022' Description: 'Secure HMAC (SHA-512) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_S_CRYPTO_TEST_1022 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1024' Description: 'Secure HMAC with long key (SHA-224) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_S_CRYPTO_TEST_1024 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1030' Description: 'Secure AEAD (AES-128-CCM) interface' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_S_CRYPTO_TEST_1030 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1031' Description: 'Secure AEAD (AES-128-GCM) interface' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_S_CRYPTO_TEST_1031 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1032' Description: 'Secure key policy interface' TEST: TFM_S_CRYPTO_TEST_1032 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1033' Description: 'Secure key policy check permissions' TEST: TFM_S_CRYPTO_TEST_1033 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1034' Description: 'Secure persistent key interface' Failed to import a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1292) TEST: TFM_S_CRYPTO_TEST_1034 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1035' Description: 'Key access control' TEST: TFM_S_CRYPTO_TEST_1035 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1036' Description: 'Secure AEAD interface with truncated auth tag (AES-128-CCM-8)' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_S_CRYPTO_TEST_1036 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1037' Description: 'Secure TLS 1.2 PRF key derivation' TEST: TFM_S_CRYPTO_TEST_1037 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1038' Description: 'Secure TLS-1.2 PSK-to-MasterSecret key derivation' TEST: TFM_S_CRYPTO_TEST_1038 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1039' Description: 'Secure HKDF key derivation' TEST: TFM_S_CRYPTO_TEST_1039 - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1040' Description: 'Secure ECDH key agreement' Error importing the private key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1390) TEST: TFM_S_CRYPTO_TEST_1040 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1041' Description: 'Secure Symmetric encryption (AES-128-OFB) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_S_CRYPTO_TEST_1041 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1042' Description: 'Secure Symmetric encryption (AES-128-ECB) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_S_CRYPTO_TEST_1042 - FAILED! > Executing 'TFM_S_CRYPTO_TEST_1043)' Description: 'Secure Asymmetric encryption interface (RSA_OAEP)' CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 TEST: TFM_S_CRYPTO_TEST_1043) - PASSED! > Executing 'TFM_S_CRYPTO_TEST_1044' Description: 'Secure Asymmetric encryption interface (RSA_PKCS1V15)' CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 TEST: TFM_S_CRYPTO_TEST_1044 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1045' Description: 'Secure Sign and verify message interface (ECDSA-SECP256R1-SHA256)' Error importing the private key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1726) TEST: TFM_NS_CRYPTO_TEST_1045 - FAILED! TESTSUITE FAILED! Number of failed tests: 11 of 31 Running Test Suite Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)... > Executing 'TFM_S_ATTEST_TEST_1004' Description: 'ECDSA signature test of attest token' TEST: TFM_S_ATTEST_TEST_1004 - PASSED! > Executing 'TFM_S_ATTEST_TEST_1005' Description: 'Negative test cases for initial attestation service' TEST: TFM_S_ATTEST_TEST_1005 - PASSED! TESTSUITE PASSED! Running Test Suite Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)... > Executing 'TFM_S_PLATFORM_TEST_1001' Description: 'Minimal platform service test' TEST: TFM_S_PLATFORM_TEST_1001 - PASSED! TESTSUITE PASSED! Running Test Suite IPC secure interface test (TFM_S_IPC_TEST_1XXX)... > Executing 'TFM_S_IPC_TEST_1001' Description: 'Accessing stateless service from secure partition' [IPC_SERVICE_TEST_STATELESS_ROT] Service called! arg=ffffabcd TEST: TFM_S_IPC_TEST_1001 - PASSED! TESTSUITE PASSED! *** Secure test suites summary *** Test suite 'PSA protected storage S interface tests (TFM_S_PS_TEST_1XXX)' has PASSED Test suite 'PS reliability tests (TFM_PS_TEST_3XXX)' has PASSED Test suite 'PS rollback protection tests (TFM_S_PS_TEST_3XXX)' has PASSED Test suite 'PSA internal trusted storage S interface tests (TFM_S_ITS_TEST_1XXX)' has FAILED Test suite 'ITS reliability tests (TFM_ITS_TEST_2XXX)' has FAILED Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has FAILED Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED Test suite 'IPC secure interface test (TFM_S_IPC_TEST_1XXX)' has PASSED *** End of Secure test suites *** Non-Secure system starting... #### Execute test suites for the Non-secure area #### Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)... > Executing 'TFM_NS_PS_TEST_1001' Description: 'Set interface' TEST: TFM_NS_PS_TEST_1001 - PASSED! > Executing 'TFM_NS_PS_TEST_1002' Description: 'Set interface with create flags' TEST: TFM_NS_PS_TEST_1002 - PASSED! > Executing 'TFM_NS_PS_TEST_1003' Description: 'Set interface with NULL data pointer' TEST: TFM_NS_PS_TEST_1003 - PASSED! > Executing 'TFM_NS_PS_TEST_1004' Description: 'Set interface with write once UID' TEST: TFM_NS_PS_TEST_1004 - PASSED! > Executing 'TFM_NS_PS_TEST_1005' Description: 'Get interface with valid data' TEST: TFM_NS_PS_TEST_1005 - PASSED! > Executing 'TFM_NS_PS_TEST_1006' Description: 'Get interface with zero data length' TEST: TFM_NS_PS_TEST_1006 - PASSED! > Executing 'TFM_NS_PS_TEST_1007' Description: 'Get interface with invalid UIDs' TEST: TFM_NS_PS_TEST_1007 - PASSED! > Executing 'TFM_NS_PS_TEST_1008' Description: 'Get interface with invalid data lengths and offsets' TEST: TFM_NS_PS_TEST_1008 - PASSED! > Executing 'TFM_NS_PS_TEST_1009' Description: 'Get interface with NULL data pointer' TEST: TFM_NS_PS_TEST_1009 - PASSED! > Executing 'TFM_NS_PS_TEST_1010' Description: 'Get info interface with write once UID' TEST: TFM_NS_PS_TEST_1010 - PASSED! > Executing 'TFM_NS_PS_TEST_1011' Description: 'Get info interface with valid UID' TEST: TFM_NS_PS_TEST_1011 - PASSED! > Executing 'TFM_NS_PS_TEST_1012' Description: 'Get info interface with invalid UIDs' TEST: TFM_NS_PS_TEST_1012 - PASSED! > Executing 'TFM_NS_PS_TEST_1013' Description: 'Remove interface with valid UID' TEST: TFM_NS_PS_TEST_1013 - PASSED! > Executing 'TFM_NS_PS_TEST_1014' Description: 'Remove interface with write once UID' TEST: TFM_NS_PS_TEST_1014 - PASSED! > Executing 'TFM_NS_PS_TEST_1015' Description: 'Remove interface with invalid UID' TEST: TFM_NS_PS_TEST_1015 - PASSED! > Executing 'TFM_NS_PS_TEST_1021' Description: 'Block compaction after remove' TEST: TFM_NS_PS_TEST_1021 - PASSED! > Executing 'TFM_NS_PS_TEST_1022' Description: 'Multiple partial gets' TEST: TFM_NS_PS_TEST_1022 - PASSED! > Executing 'TFM_NS_PS_TEST_1023' Description: 'Multiple sets to same UID from same thread' TEST: TFM_NS_PS_TEST_1023 - PASSED! > Executing 'TFM_NS_PS_TEST_1024' Description: 'Get support interface' TEST: TFM_NS_PS_TEST_1024 - PASSED! > Executing 'TFM_NS_PS_TEST_1025' Description: 'Set, get and remove interface with different asset sizes' TEST: TFM_NS_PS_TEST_1025 - PASSED! TESTSUITE PASSED! Running Test Suite PSA internal trusted storage NS interface tests (TFM_NS_ITS_TEST_1XXX)... > Executing 'TFM_NS_ITS_TEST_1001' Description: 'Set interface' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:32) TEST: TFM_NS_ITS_TEST_1001 - FAILED! > Executing 'TFM_NS_ITS_TEST_1002' Description: 'Set interface with create flags' Note: The UID in this test has already been created with the PSA_STORAGE_FLAG_WRITE_ONCE flag in a previous test run. Wipe the storage area to run the full test. TEST: TFM_NS_ITS_TEST_1002 - PASSED! > Executing 'TFM_NS_ITS_TEST_1003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:115) TEST: TFM_NS_ITS_TEST_1003 - FAILED! > Executing 'TFM_NS_ITS_TEST_1004' Description: 'Set interface with write once UID' Get should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:146) TEST: TFM_NS_ITS_TEST_1004 - FAILED! > Executing 'TFM_NS_ITS_TEST_1005' Description: 'Get interface with valid data' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:186) TEST: TFM_NS_ITS_TEST_1005 - FAILED! > Executing 'TFM_NS_ITS_TEST_1006' Description: 'Get interface with zero data length' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:293) TEST: TFM_NS_ITS_TEST_1006 - FAILED! > Executing 'TFM_NS_ITS_TEST_1007' Description: 'Get interface with invalid UIDs' TEST: TFM_NS_ITS_TEST_1007 - PASSED! > Executing 'TFM_NS_ITS_TEST_1008' Description: 'Get interface with invalid data lengths and offsets' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:426) TEST: TFM_NS_ITS_TEST_1008 - FAILED! > Executing 'TFM_NS_ITS_TEST_1009' Description: 'Get interface with NULL data pointer' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:541) TEST: TFM_NS_ITS_TEST_1009 - FAILED! > Executing 'TFM_NS_ITS_TEST_1010' Description: 'Get info interface with write once UID' TEST: TFM_NS_ITS_TEST_1010 - PASSED! > Executing 'TFM_NS_ITS_TEST_1011' Description: 'Get info interface with valid UID' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:612) TEST: TFM_NS_ITS_TEST_1011 - FAILED! > Executing 'TFM_NS_ITS_TEST_1012' Description: 'Get info interface with invalid UIDs' TEST: TFM_NS_ITS_TEST_1012 - PASSED! > Executing 'TFM_NS_ITS_TEST_1013' Description: 'Remove interface with valid UID' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:708) TEST: TFM_NS_ITS_TEST_1013 - FAILED! > Executing 'TFM_NS_ITS_TEST_1014' Description: 'Remove interface with write once UID' TEST: TFM_NS_ITS_TEST_1014 - PASSED! > Executing 'TFM_NS_ITS_TEST_1015' Description: 'Remove interface with invalid UID' TEST: TFM_NS_ITS_TEST_1015 - PASSED! > Executing 'TFM_NS_ITS_TEST_1016' Description: 'Block compaction after remove' Set should not fail for UID 1 (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:790) TEST: TFM_NS_ITS_TEST_1016 - FAILED! > Executing 'TFM_NS_ITS_TEST_1017' Description: 'Multiple partial gets' Set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:860) TEST: TFM_NS_ITS_TEST_1017 - FAILED! > Executing 'TFM_NS_ITS_TEST_1018' Description: 'Multiple sets to same UID from same thread' First set should not fail (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:911) TEST: TFM_NS_ITS_TEST_1018 - FAILED! > Executing 'TFM_NS_ITS_TEST_1019' Description: 'Set, get and remove interface with different asset sizes' Set should not fail with valid UID (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/its/its_tests_common.c:995) TEST: TFM_NS_ITS_TEST_1019 - FAILED! TESTSUITE FAILED! Number of failed tests: 13 of 19 Running Test Suite Crypto non-secure interface test (TFM_NS_CRYPTO_TEST_1XXX)... > Executing 'TFM_NS_CRYPTO_TEST_1001' Description: 'Non Secure Key management interface' TEST: TFM_NS_CRYPTO_TEST_1001 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1002' Description: 'Non Secure Symmetric encryption (AES-128-CBC) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_NS_CRYPTO_TEST_1002 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1005' Description: 'Non Secure Symmetric encryption (AES-128-CTR) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_NS_CRYPTO_TEST_1005 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1007' Description: 'Non Secure Symmetric encryption invalid cipher' TEST: TFM_NS_CRYPTO_TEST_1007 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1008' Description: 'Non Secure Symmetric encryption invalid cipher (AES-152)' TEST: TFM_NS_CRYPTO_TEST_1008 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1010' Description: 'Non Secure Unsupported Hash (SHA-1) interface' TEST: TFM_NS_CRYPTO_TEST_1010 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1011' Description: 'Non Secure Hash (SHA-224) interface' TEST: TFM_NS_CRYPTO_TEST_1011 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1012' Description: 'Non Secure Hash (SHA-256) interface' TEST: TFM_NS_CRYPTO_TEST_1012 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1013' Description: 'Non Secure Hash (SHA-384) interface' TEST: TFM_NS_CRYPTO_TEST_1013 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1014' Description: 'Non Secure Hash (SHA-512) interface' TEST: TFM_NS_CRYPTO_TEST_1014 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1019' Description: 'Non Secure Unsupported HMAC (SHA-1) interface' TEST: TFM_NS_CRYPTO_TEST_1019 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1020' Description: 'Non Secure HMAC (SHA-256) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_NS_CRYPTO_TEST_1020 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1021' Description: 'Non Secure HMAC (SHA-384) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_NS_CRYPTO_TEST_1021 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1022' Description: 'Non Secure HMAC (SHA-512) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_NS_CRYPTO_TEST_1022 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1024' Description: 'Non Secure HMAC with long key (SHA-224) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:634) TEST: TFM_NS_CRYPTO_TEST_1024 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1030' Description: 'Non Secure AEAD (AES-128-CCM) interface' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_NS_CRYPTO_TEST_1030 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1031' Description: 'Non Secure AEAD (AES-128-GCM) interface' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_NS_CRYPTO_TEST_1031 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1032' Description: 'Non Secure key policy interface' TEST: TFM_NS_CRYPTO_TEST_1032 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1033' Description: 'Non Secure key policy check permissions' TEST: TFM_NS_CRYPTO_TEST_1033 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1034' Description: 'Non Secure persistent key interface' Failed to import a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1292) TEST: TFM_NS_CRYPTO_TEST_1034 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1035' Description: 'Non Secure AEAD interface with truncated auth tag (AES-128-CCM-8)' Algorithm NOT SUPPORTED by the implementation - skip multipart API flow TEST: TFM_NS_CRYPTO_TEST_1035 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1036' Description: 'Non Secure TLS 1.2 PRF key derivation' TEST: TFM_NS_CRYPTO_TEST_1036 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1037' Description: 'Non Secure TLS-1.2 PSK-to-MasterSecret key derivation' TEST: TFM_NS_CRYPTO_TEST_1037 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1038' Description: 'Non Secure HKDF key derivation' TEST: TFM_NS_CRYPTO_TEST_1038 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1039' Description: 'Non Secure ECDH key agreement' Error importing the private key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1390) TEST: TFM_NS_CRYPTO_TEST_1039 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1040' Description: 'Non Secure Symmetric encryption (AES-128-OFB) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_NS_CRYPTO_TEST_1040 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1041' Description: 'Non Secure Symmetric encryption (AES-128-ECB) interface' Error importing a key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:140) TEST: TFM_NS_CRYPTO_TEST_1041 - FAILED! > Executing 'TFM_NS_CRYPTO_TEST_1042' Description: 'Non Secure Asymmetric encryption interface (RSA_OAEP)' CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 TEST: TFM_NS_CRYPTO_TEST_1042 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1043' Description: 'Non Secure Asymmetric encryption interface (RSA_PKCS1V15)' CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 CC:error_mapping_cc_to_mbedtls_rsa: Converted CC_ERROR 0 (0x00000000) to MBEDTLS_ERR 0 TEST: TFM_NS_CRYPTO_TEST_1043 - PASSED! > Executing 'TFM_NS_CRYPTO_TEST_1044' Description: 'Non Secure Sign and verify message interface (ECDSA-SECP256R1-SHA256)' Error importing the private key (Failed at D:/Projects/tf-m6/trusted-firmware-m/armclang/lib/ext/tfm_test_repo-src/test/suites/crypto/crypto_tests_common.c:1726) TEST: TFM_NS_CRYPTO_TEST_1044 - FAILED! TESTSUITE FAILED! Number of failed tests: 11 of 30 Running Test Suite Platform Service Non-Secure interface tests(TFM_NS_PLATFORM_TEST_1XXX)... > Executing 'TFM_NS_PLATFORM_TEST_1001' Description: 'Minimal platform service test' TEST: TFM_NS_PLATFORM_TEST_1001 - PASSED! TESTSUITE PASSED! Running Test Suite Initial Attestation Service non-secure interface tests(TFM_NS_ATTEST_TEST_1XXX)... > Executing 'TFM_NS_ATTEST_TEST_1004' Description: 'ECDSA signature test of attest token' TEST: TFM_NS_ATTEST_TEST_1004 - PASSED! > Executing 'TFM_NS_ATTEST_TEST_1005' Description: 'Negative test cases for initial attestation service' TEST: TFM_NS_ATTEST_TEST_1005 - PASSED! TESTSUITE PASSED! Running Test Suite QCBOR regression test(TFM_NS_QCBOR_TEST_1XXX)... > Executing 'TFM_NS_QCBOR_TEST_1001' Description: 'Regression test of QCBOR library' TEST: TFM_NS_QCBOR_TEST_1001 - PASSED! TESTSUITE PASSED! Running Test Suite T_COSE regression test(TFM_NS_T_COSE_TEST_1XXX)... > Executing 'TFM_NS_T_COSE_TEST_1001' Description: 'Regression test of t_cose library' TEST: TFM_NS_T_COSE_TEST_1001 - PASSED! TESTSUITE PASSED! Running Test Suite PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)... > Executing 'TFM_NS_FWU_TEST_1001' Description: 'Write, install and abort interface' TEST: TFM_NS_FWU_TEST_1001 - PASSED! > Executing 'TFM_NS_FWU_TEST_1003' Description: 'Write interface with image_offset + block_size overflow' TFM FWU: write flash failed. TEST: TFM_NS_FWU_TEST_1003 - PASSED! > Executing 'TFM_NS_FWU_TEST_1004' Description: 'Install interface with NULL dependency uuid' TEST: TFM_NS_FWU_TEST_1004 - PASSED! > Executing 'TFM_NS_FWU_TEST_1005' Description: 'Install interface with NULL dependency version' TEST: TFM_NS_FWU_TEST_1005 - PASSED! > Executing 'TFM_NS_FWU_TEST_1006' Description: 'Install before write' TEST: TFM_NS_FWU_TEST_1006 - PASSED! > Executing 'TFM_NS_FWU_TEST_1007' Description: 'Install after abort' TEST: TFM_NS_FWU_TEST_1007 - PASSED! > Executing 'TFM_NS_FWU_TEST_1008' Description: 'Abort interface with no image is being installing' TEST: TFM_NS_FWU_TEST_1008 - PASSED! > Executing 'TFM_NS_FWU_TEST_1009' Description: 'Query interface with the active image' TEST: TFM_NS_FWU_TEST_1009 - PASSED! > Executing 'TFM_NS_FWU_TEST_1011' Description: 'Query interface invald image id' TFM FWU: invalid slot_id: 3 TEST: TFM_NS_FWU_TEST_1011 - PASSED! > Executing 'TFM_NS_FWU_TEST_1012' Description: 'Accept interface' TEST: TFM_NS_FWU_TEST_1012 - PASSED! > Executing 'TFM_NS_FWU_TEST_1014' Description: 'Image update with dependency, no new image is required' TEST: TFM_NS_FWU_TEST_1014 - PASSED! > Executing 'TFM_NS_FWU_TEST_1015' Description: 'Image update with dependency, new image is required' TEST: TFM_NS_FWU_TEST_1015 - PASSED! > Executing 'TFM_NS_FWU_TEST_1016' Description: 'psa_fwu_write boundary test' TEST: TFM_NS_FWU_TEST_1016 - PASSED! TESTSUITE PASSED! Running Test Suite Core non-secure positive tests (TFM_NS_CORE_TEST_1XXX)... > Executing 'TFM_NS_CORE_TEST_1001' Description: 'Test service request from NS thread mode' TEST: TFM_NS_CORE_TEST_1001 - PASSED! > Executing 'TFM_NS_CORE_TEST_1003' Description: 'Test the success of service init' TEST: TFM_NS_CORE_TEST_1003 - PASSED! > Executing 'TFM_NS_CORE_TEST_1007' Description: 'Test secure service buffer accesses' TEST: TFM_NS_CORE_TEST_1007 - PASSED! > Executing 'TFM_NS_CORE_TEST_1008' Description: 'Test secure service to service call' TEST: TFM_NS_CORE_TEST_1008 - PASSED! > Executing 'TFM_NS_CORE_TEST_1010' Description: 'Test secure service to service call with buffer handling' TEST: TFM_NS_CORE_TEST_1010 - PASSED! > Executing 'TFM_NS_CORE_TEST_1014' Description: 'Test service parameter sanitization' TEST: TFM_NS_CORE_TEST_1014 - PASSED! > Executing 'TFM_NS_CORE_TEST_1015' Description: 'Test outvec write' TEST: TFM_NS_CORE_TEST_1015 - PASSED! TESTSUITE PASSED! Running Test Suite IPC non-secure interface test (TFM_NS_IPC_TEST_1XXX)... > Executing 'TFM_NS_IPC_TEST_1001' Description: 'Get PSA framework version' The version of the PSA Framework API is 257. TEST: TFM_NS_IPC_TEST_1001 - PASSED! > Executing 'TFM_NS_IPC_TEST_1002' Description: 'Get version of an RoT Service' The service version is 1. TEST: TFM_NS_IPC_TEST_1002 - PASSED! > Executing 'TFM_NS_IPC_TEST_1003' Description: 'Connect to an RoT Service' Connect success! TEST: TFM_NS_IPC_TEST_1003 - PASSED! > Executing 'TFM_NS_IPC_TEST_1004' Description: 'Call an RoT Service' TFM service support version is 1. psa_call is successful! outvec1 is: It is just for IPC call test. outvec2 is: It is just for IPC call test. TEST: TFM_NS_IPC_TEST_1004 - PASSED! > Executing 'TFM_NS_IPC_TEST_1005' Description: 'Call IPC_INIT_BASIC_TEST service' Connect success! Call success! TEST: TFM_NS_IPC_TEST_1005 - PASSED! > Executing 'TFM_NS_IPC_TEST_1006' Description: 'Call PSA RoT access APP RoT memory test service' Connect success! Call success! TEST: TFM_NS_IPC_TEST_1006 - PASSED! > Executing 'TFM_NS_IPC_TEST_1010' Description: 'Test psa_call with the status of PSA_ERROR_PROGRAMMER_ERROR' Connect success! The first time call success! The second time call success! TEST: TFM_NS_IPC_TEST_1010 - PASSED! > Executing 'TFM_NS_IPC_TEST_1012' Description: 'Accessing stateless service from non-secure client' [IPC_SERVICE_TEST_STATELESS_ROT] Service called! arg=ffffabcd TEST: TFM_NS_IPC_TEST_1012 - PASSED! TESTSUITE PASSED! Running Test Suite TFM IRQ Test (TFM_IRQ_TEST_1xxx)... > Executing 'TFM_NS_IRQ_TEST_SLIH_1001' Description: 'SLIH HANDLING Case 1' TEST: TFM_NS_IRQ_TEST_SLIH_1001 - PASSED! TESTSUITE PASSED! *** Non-secure test suites summary *** Test suite 'PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)' has PASSED Test suite 'PSA internal trusted storage NS interface tests (TFM_NS_ITS_TEST_1XXX)' has FAILED Test suite 'Crypto non-secure interface test (TFM_NS_CRYPTO_TEST_1XXX)' has FAILED Test suite 'Platform Service Non-Secure interface tests(TFM_NS_PLATFORM_TEST_1XXX)' has PASSED Test suite 'Initial Attestation Service non-secure interface tests(TFM_NS_ATTEST_TEST_1XXX)' has PASSED Test suite 'QCBOR regression test(TFM_NS_QCBOR_TEST_1XXX)' has PASSED Test suite 'T_COSE regression test(TFM_NS_T_COSE_TEST_1XXX)' has PASSED Test suite 'PSA firmware update NS interface tests (TFM_NS_FWU_TEST_1xxx)' has PASSED Test suite 'Core non-secure positive tests (TFM_NS_CORE_TEST_1XXX)' has PASSED Test suite 'IPC non-secure interface test (TFM_NS_IPC_TEST_1XXX)' has PASSED Test suite 'TFM IRQ Test (TFM_IRQ_TEST_1xxx)' has PASSED *** End of Non-secure test suites *** -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

3 years, 5 months

1
0
0 0

nucleo_l552ze_q platform does not build since TF-M 1.5

by Michel JAOUEN

Hello, This platform is tested for profile medium and low (-DTFM_PROFILE=profile_small or -DTFM_PROFILE=profile_medium). I just checked on master with medium profile and GNUARM. The default config takes a crypto config with its associated crypto tests that leads to overlap in flash area. (This device has 512Kbytes Flash) Best Regards ST Restricted From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bøe, Sebastian via TF-M Sent: mercredi 22 décembre 2021 13:40 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] nucleo_l552ze_q platform does not build since TF-M 1.5 Hi, I am observing that the nucleo_l552ze_q platform is producing hex files that overlap since the 1.5 release. Tested on master and 1.5. Is there an STM maintainer that could look into this? Steps to reproduce: rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex") "/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced with the preferred hex file merging tool. output: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files ih.merge(to_merge, overlap=overlap) File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge raise AddressOverlapError( intelhex.AddressOverlapError: Data overlapped at address 0xC014400 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module> main() File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main merge_hex_files(args.output, args.input_files, args.overlap) File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files raise AddressOverlapError("{} has merge issues".format(hex_file_path)) intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues PS: Depending on the revision tested, it might be necessary to also apply this patch: modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt @@ -90,7 +90,7 @@ target_sources(platform_s ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c - $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system> + $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c> ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c PUBLIC

3 years, 6 months

2
1
0 0

nucleo_l552ze_q platform does not build since TF-M 1.5

by Bøe, Sebastian

Hi, I am observing that the nucleo_l552ze_q platform is producing hex files that overlap since the 1.5 release. Tested on master and 1.5. Is there an STM maintainer that could look into this? Steps to reproduce: rm -rf cmake_build && cmake -S . -B cmake_build -DTFM_PLATFORM=stm/nucleo_l552ze_q -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=MinSizeRel -DTEST_S=ON -DTEST_NS=ON && make -C cmake_build install && /usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py -o merged.hex $(find cmake_build -name "*.hex") "/usr/bin/python3.8 /home/sebo/ncs/zephyr/scripts/mergehex.py" must be replaced with the preferred hex file merging tool. output: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 28, in merge_hex_files ih.merge(to_merge, overlap=overlap) File "/home/sebo/.local/lib/python3.8/site-packages/intelhex/__init__.py", line 875, in merge raise AddressOverlapError( intelhex.AddressOverlapError: Data overlapped at address 0xC014400 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 56, in <module> main() File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 52, in main merge_hex_files(args.output, args.input_files, args.overlap) File "/home/sebo/ncs/zephyr/scripts/mergehex.py", line 30, in merge_hex_files raise AddressOverlapError("{} has merge issues".format(hex_file_path)) intelhex.AddressOverlapError: cmake_build/install/outputs/STM/NUCLEO_L552ZE_Q/tfm_s.hex has merge issues PS: Depending on the revision tested, it might be necessary to also apply this patch: modified platform/ext/target/stm/common/stm32l5xx/CMakeLists.txt @@ -90,7 +90,7 @@ target_sources(platform_s ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_gtzc.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_isolation_mpu_v8m.c ${CMAKE_SOURCE_DIR}/platform/ext/common/tfm_hal_nvic.c - $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system> + $<$<BOOL:${TFM_PARTITION_PLATFORM}>:${CMAKE_CURRENT_SOURCE_DIR}/secure/tfm_platform_system.c> ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng.c ${CMAKE_CURRENT_SOURCE_DIR}/hal/Src/stm32l5xx_hal_rng_ex.c PUBLIC

3 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M