- TF-M - lists.trustedfirmware.org

[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, 8 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 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, 9 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, 9 months

1
0
0 0

unsubscribe

by st9hack＠yahoo.com

unsubscribe

3 years, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 10 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M