- TF-M - lists.trustedfirmware.org

by Reinhard Keil

I suggest we review the requirement of code isolation on the secure side. R/W data and R/O data should definitely be isolated, but code isolation has implications: * Code cannot be share between services (i.e. no linker optimization to reduce memory footprint) * Sharing library code * Overall the build instructions of the system are more complicated * Adding device specific driver code (i.e. to crypto) can become tricky Reinhard 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. 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.

5 years, 4 months

1
0
0 0

The logging mechanism change in TF-M

by Reinhard Keil

I recommend instead of using printf with plain text strings, to change the concept to event annotations. This is already implemented in several RTOS systems (i.e. FreeRTOS or RTX). Event annotations give you more flexibility: * can be mapped to memory buffer, printf output, or analysers like Event Recorder in MDK or Percepio * annotations are described in XML file using event groups. Can be mapped to test automation systems and reduce overhead * no direct mapping to a peripheral. UART may be not available on all systems. * overall less overhead in the system (as printf is expensive). Can remain in production code when it just goes to memory buffer Let me know if you want to have further pointers or information. Reinhard 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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Got 3 feedbacks till now all reports no problem. I am going to merge this one before end of today. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 1:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 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: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Thanks Thomas, then IAR won't be a difficult part for this. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 8, 2020 7:45 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: Hi, ï¿½ As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: ï¿½ - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. ï¿½ With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. ï¿½ Please help to check these point before applying '-fno-builtin' and provide your feedback: ï¿½ - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? ï¿½ Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. ï¿½ Thanks! ï¿½ /Ken -- 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<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

Re: [TF-M] [Request For Comments] apply "-fno-builtin" as default compiler flags

by Thomas Törnblom

The IAR toolchain does not produce any special "builtin" calls and thus does not have any flag similar to "-fno-builtin". /Thomas Den 2020-01-08 kl. 03:53, skrev Ken Liu via TF-M: > > Hi, > > As TF-M needs runtime APIs so we are creating the Secure Partition > runtime library, code is ready but we have not forwarded all necessary > runtime APIs to the version TF-M implemented, this was caused by the > toolchain optimization for built-in APIs, such as: > > - Forward printf(%s) to puts if there is only one string parameter. > > - ARMCLANG would forward memxxx API into an optimized variant. > > With the '-fno-builtin' flags set in the toolchain, this optimization > would be disabled so that user just implement the same name built-in > to replace the toolchain version. > > Please help to check these point before applying '-fno-builtin' and > provide your feedback: > > - Could toolchains out of ARMCLANG and GNUARM have a similar flag? > > - Would it affect your project setting and how does it affect? > > Please help to feedback. I will keep this thread open for ~1 week and > let's get a conclusion after this. > > Thanks! > > /Ken > > -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Anton Komlev

Hi All, Thanks, Ken and Edison for offering the topics for tomorrow's Tech forum. The agenda (always open) starts from: 1. Secure Partition Runtime Library 2. PSA FF 1.0.0 alignment Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: 07 January 2020 08:19 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 7, 2020 3:33 PM 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] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken 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: Tuesday, January 7, 2020 1:56 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: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

[Request For Comments] apply "-fno-builtin" as default compiler flags

by Ken Liu

Hi, As TF-M needs runtime APIs so we are creating the Secure Partition runtime library, code is ready but we have not forwarded all necessary runtime APIs to the version TF-M implemented, this was caused by the toolchain optimization for built-in APIs, such as: - Forward printf(%s) to puts if there is only one string parameter. - ARMCLANG would forward memxxx API into an optimized variant. With the '-fno-builtin' flags set in the toolchain, this optimization would be disabled so that user just implement the same name built-in to replace the toolchain version. Please help to check these point before applying '-fno-builtin' and provide your feedback: - Could toolchains out of ARMCLANG and GNUARM have a similar flag? - Would it affect your project setting and how does it affect? Please help to feedback. I will keep this thread open for ~1 week and let's get a conclusion after this. Thanks! /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 07/01/2020 01:23, Ken Liu via TF-M wrote: > Hi Soby, > > Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. > > One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? > > /Ken Hi Ken, The TF-A uses -fno-builtin compiler flag. Hence it doesn't face this problem. If the goal is to not to pull in compiler builtin libraries, setting this flag would be the right approach. The TF-M source tree would need to provide libc. Best Regards Soby Mathew

5 years, 4 months

2
1
0 0

Last call for reviewing TIMER IRQ naming

by Alamy Liu

Hi all, Please help to review the patch, and it would be merged soon if there is no other comment https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687 Best Regards, Alamy

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Edison Ai

Hi Anton, I will share something about the PSA FF 1.0.0 alignment. About 10 - 15 minutes. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 7, 2020 3:33 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - January 9 Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken 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: Tuesday, January 7, 2020 1:56 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: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - January 9

by Ken Liu

Hi Anton, I can share the status of Secure Partition Runtime Library in the tech forum. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, January 7, 2020 1:56 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - January 9 Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Ken Liu

Hi Soby, Thanks for providing the reference - we have investigated the version in TF-A earlier, the difference part is we are facing the problem about how to flush the formatted data into device - TF-A has full control to the device so it could just output_char() but the secure partition cannot do this due to some driver sharing consideration. We can reference the TF-A implementation after the logging device mechanism is settled down. One question, the ARM Complier built-in would change printf to puts or some other variants in RVCT like __2printf, I searched TF-A sources found there is no '--fbulit-in' or 'no_scanlib' flags for the compiler but looks like TF-A has not met the scenarios TF-M met? Or...the runtime library mechanism for A and M are different? /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: Monday, January 6, 2020 9:35 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The logging mechanism change in TF-M On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() > for the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Ken Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in > exceptions can be – there is a trade-off between security > consideration (isolation) and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Updated invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 4 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 9 Jan 2020 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

You have been invited to the following event. 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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 9 Jan 2020 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Joining info: Join Hangouts Meet https://meet.google.com/xdb-txmc-xje Or dial: +44 20 3956 3237 (PIN:: 515715720) More phone numbers: https://tel.meet/xdb-txmc-xje?pin=7033981256503&hs=0 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=NTZtNXZwM3BsaGltanJkb… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 4 months

1
0
0 0

TF-M Technical Forum call - January 9

by Anton Komlev

Hello, Hope that the new year is truly happy for everybody. The next session of the Technical Forum is planned on the coming Thursday, January 9th. Regarding the time, I think that the last session was a good compromise to suit majority of the participants so propose to keep the time slot at 7:00-8:00 UTC. This time suits members in Europe and Asia, although participants from US (specially from the East coast) might have inconveniences. Reminding that the recorded sessions and materials are available on the web site: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Please reply to this email to post your topics for the agenda. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. Best regards, Anton Komlev

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

> Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? This is essentially correct. As this is outside of the PSA-FF at present, TF-M would need to design and document how to integrate such IRQ handlers with its interrupt management framework, and how the interrupt handler can interact with the secure service code. For example, this might be achieved by resuming a SFC call that is waiting for a hardware operation to complete or delivering a signal to an IPC mode Secure Partition. 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Soby Mathew

On 06/01/2020 11:45, Anton Komlev via TF-M wrote: > Hi Ken, All, > > I like your approach of providing a minimalistic version of printf() for > the logging purpose only. > > This would benefit to code size and performance while rich print > formatting has no practical needs in this project. > > Best regards, > > Anton > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Ken > Liu via TF-M > *Sent:* 27 December 2019 03:38 > *To:* tf-m(a)lists.trustedfirmware.org > *Cc:* nd <nd(a)arm.com> > *Subject:* [TF-M] The logging mechanism change in TF-M > > Hi, > > We met some issues while implementing logging APIs like printf: > > * The build-in symbol optimization references other toolchain provided > symbols into image (like change ‘printf’ to ‘puts’ or ‘xxxprintf’), > this would happen in both we are implementing your ‘printf’ and > referencing toolchain ‘printf’. Use a -fno-builtin would suppress > this but this needs a compiler flag requirement for developers. > * If we don’t provide necessary symbol but somewhere in program > referenced it, ARMCLANG would provide one for us which contains the > semihosting things, this increases the code size and cause trouble > while the device is not running under semihosting env. > * Also there are CMSIS user reports that __stdout would affect > multiple thread object initialization. (No detail about the root > cause, anyone could help provide something?) > > So it would be better that we remove the reference to toolchain stdout > APIs, this could simplify the logging implementation since firmware > logging MAY not need rich format (Comments?). A customized printf-like > API is provided for logging but not being named as ‘printf’ directly. > > Due to the default logging device (UART) driver may be implemented for > threads only, the logging functionality in exceptions is going to be > suppressed for a while until we figure out how the logging in exceptions > can be – there is a trade-off between security consideration (isolation) > and performance (Routing the logging API to somewhere costs). > > Please provide your thinking, or what kind of logging API you are using. > > Thanks > > /Ken > The TF-A code base provides a reduced printf() functionality due to similar concerns and to reduce stack/memory usage https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/libc/p… Also be aware that mbedTLS requires snprintf() so if printf() is being custom implemented, then it makes sense to do the same to snprintf() as well. Best Regards Soby Mathew

5 years, 4 months

1
0
0 0

Re: [TF-M] The logging mechanism change in TF-M

by Anton Komlev

Hi Ken, All, I like your approach of providing a minimalistic version of printf() for the logging purpose only. This would benefit to code size and performance while rich print formatting has no practical needs in this project. Best regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 December 2019 03:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The logging mechanism change in TF-M Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] System reset SPM HAL function

by Edison Ai

This patch will add a new system reset function for SPM without using the existing platform_hal_system_reset(). The basic thinking is to create a dedicated HAL function for SPM to split with services, and not affect the secure partition work. I am not sure if this will bring some problems or any potential risk for platform porting. Please give feedback about this in this mail thread. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai via TF-M Sent: Monday, December 30, 2019 3:43 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] System reset SPM HAL function Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

5 years, 4 months

1
0
0 0

Secure Partition runtime library prototype is available

by Ken Liu

Hi, After couples of patches get merged, the Secure Partition runtime library prototype is available. The purpose of this library (aka SPRTL) is to provide a place for shared functions between secure partitions under isolation level 2/3 which could avoid duplicated code symbols in Secure Partitions. The situation is: - There is a folder for SPE dedicated function implementation: 'secure_fw/lib/sprt'. More APIs can be put in SPRTL by modifying the makefiles under this folder. - Keep using toolchain provided 'memset/memcpy' due to inherit them is a bit complicated (of course these toolchain symbols are put in the shared region to avoid duplication). And we keep the customized candidate in source code for further investigation to see if we need this customized version or the default version. - Overriding toolchain 'memcmp' into a customized version to show security consideration. - Implemented a customized 'tfm_log_printf' to replace 'printf', which could avoid involving complicated STDIO mechanism into the code base. - PSA FF APIs are now in it. These changes are now working under the code base, some other functions are not available yet and to be done later due to no actual requirement for them, such as: - Heap APIs, now crypto uses its own implemented heap while other services do not need them. - RoT Service APIs, would request service owner to move the existing RoT Service APIs into SPRTL (should be just some function attribute change, let's check it). Any feedbacks or issue reporting is welcome, please reply in the mailing list or create an issue at developer.trustedfirmware.org and assign to 'KenLSoft'. BR and thanks. /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Thanks for the feedback, let me take a note. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Qixiang Xu via TF-M Sent: Monday, January 6, 2020 1:49 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 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: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Qixiang Xu

Ken, I have cherry picked the patch and tested it on Cygwin: $ cmake --version cmake version 3.11.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). The patch works and no issue found. Best Regards, Qixiang Xu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, January 6, 2020 11:00 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Call for cygwin volunteers] Remove the mbed-crypto building workaround Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken 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.

5 years, 4 months

1
0
0 0

[Call for cygwin volunteers] Remove the mbed-crypto building workaround

by Ken Liu

Hi, I create a patch for removing the workaround for mbed-crypto building: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3022 We tried on cmake 3.7 and 3.10 with cygwin and it works; can some Cygwin/mingw user pick this patch and test if it could work in your side? Thanks for your contribution 😊 /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Reinhard Keil

Hi Andrew, Thanks for the reply and the confirmation of the flexibility of the PSA-FF Just a question: For Isolation Level 1, the hardware features of v8-M should be sufficient to implement interrupts natively. Is this correct understanding or did I miss anything? Reinhard 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.

5 years, 4 months

1
0
0 0

[RFC] TF-M core updates

by Ken Liu

Hi TF-Mers, Happy new year! Till now, the core has evolved much and keep evolving. Let's take a breath before we go further, some updates are on the table and wait for comments. Most of the core changes will not affect the usage, but there do have interface related parts needs to be mentioned. Here are the overall topics for comments: - SPM/core sources renaming and changes, I think this part won't affect user much except those who copied sources into your own project and do the integration. - The HAL design is on the way, this part do affect the existing platform integration, please take apart in the discussions for this topic (The design would come first). - Some interface sources changing. Those PSA APIs won't be changed, but the folder name and place may be updated so you may need to change your project setting. We also got some new features, the design would go first and they would be merged after the update is done (Ideally ;)). Such as interrupt logic/test publish. These changes are trying to make the platform integration easier, so your feedback is important before these changes take place. And, it also makes the contribution to core logic easier. If you find something is missing, feel free to propose it here and we can discuss how much we could cover. The detailed topics would be sent one by one (avoid makes everyone too busy). Please put comments ;) Thanks /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] Initialize IPC SPM in handler mode

by Ken Liu

Almost miss the link 😉 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2964 /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, December 30, 2019 6:45 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Initialize IPC SPM in handler mode Hi, The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too. For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread’s stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away. So SPM must work under MSP to avoid touching his standing place – and, the used part of initial thread stack needs to be clean up, for security issues. Now we can’t find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware. The patches is on the way for this purpose – and follows the patches of jumping to ns without cmse call – cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode. Patches would come later (I am testing if it could on different platforms). Thanks. /Ken

5 years, 4 months

1
0
0 0

Initialize IPC SPM in handler mode

by Ken Liu

Hi, The existing SPM initialization is done in thread mode with PSP, because library model needs to enumerate the partition initialization function in thread mode. And IPC SPM re-uses the code so it is get initialized in this mode, too. For IPC SPM, it needs to initial thread context and push the initial EXC_RETURN context in each thread's stack, and the veneer thread (which belongs to non-secure partition instance) re-uses the stack of initial thread mode. This may cause problem since SPM is manipulating the stack it is now standing on. It does not cause problem now is because SPM initialization is working at the low end of stack pointer while the thread context is written at high end stack bottom, and SPM initialization would not return to thread, it just enters PendSV and then go away. So SPM must work under MSP to avoid touching his standing place - and, the used part of initial thread stack needs to be clean up, for security issues. Now we can't find a better way to clean both the used PSP stack and the MSP stack, unless we clear the PSP manually while working with MSP, and do a EXC_RETURN from handler mode to reset the MSP stack usage by hardware. The patches is on the way for this purpose - and follows the patches of jumping to ns without cmse call - cmse call consumes secure stack during the calling while we want a known stack position to identify the caller frames in handler mode. Patches would come later (I am testing if it could on different platforms). Thanks. /Ken

5 years, 4 months

1
0
0 0

System reset SPM HAL function

by Edison Ai

Hi All, To align with PSA FF 1.0.0, the SPM needs to restart the entire system when some programmer error or panics are detected. So I had upstream a patch to add a system reset HAL function for SPM: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2780/. The basic idea is to add a weak common function so that the platform can use this weak function to do reset. Please note, the platform needs to add its own implementation if there is any different. Unfortunately, there is no such test to test the system reset function curreetly. So please call psa_panic() in secure services for simple testing based on the top of this link: https://review.trustedfirmware.org/#/q/topic:tfm_panic+(status:open+OR+stat…. You can send mail or add comments directly in patches if you have any questions or comments. Thanks, Edison

5 years, 4 months

1
0
0 0

The logging mechanism change in TF-M

by Ken Liu

Hi, We met some issues while implementing logging APIs like printf: * The build-in symbol optimization references other toolchain provided symbols into image (like change 'printf' to 'puts' or 'xxxprintf'), this would happen in both we are implementing your 'printf' and referencing toolchain 'printf'. Use a -fno-builtin would suppress this but this needs a compiler flag requirement for developers. * If we don't provide necessary symbol but somewhere in program referenced it, ARMCLANG would provide one for us which contains the semihosting things, this increases the code size and cause trouble while the device is not running under semihosting env. * Also there are CMSIS user reports that __stdout would affect multiple thread object initialization. (No detail about the root cause, anyone could help provide something?) So it would be better that we remove the reference to toolchain stdout APIs, this could simplify the logging implementation since firmware logging MAY not need rich format (Comments?). A customized printf-like API is provided for logging but not being named as 'printf' directly. Due to the default logging device (UART) driver may be implemented for threads only, the logging functionality in exceptions is going to be suppressed for a while until we figure out how the logging in exceptions can be - there is a trade-off between security consideration (isolation) and performance (Routing the logging API to somewhere costs). Please provide your thinking, or what kind of logging API you are using. Thanks /Ken

5 years, 4 months

1
0
0 0

Re: [TF-M] [RFC] Code restructure of core/spm

by Ken Liu

Hi, I want to arise this topic again - some patches are blocked due to feature implementation but I think now it is a good chance since staging tag has been done. Will notify you with the patches - don't worry, it is just about some file rename in core/spm folder so if your patch does not rely on these folders a simple rebase should work for your patch. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, August 29, 2019 4:49 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Code restructure of core/spm Two more patches added under this topic: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1836 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1837 BR /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Thursday, August 15, 2019 3:15 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [RFC] Code restructure of core/spm > > Hi, > The first patch for moving header files is ready at: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1561 > Comments are welcome. I had thought to push patches together but looks > like it would block other patches for a while to show a neat merged > list, so I would push them one by one. > > Will keep you update when incoming patches are ready. > > BR > > /Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Thursday, August 1, 2019 11:12 AM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [TF-M] [RFC] Code restructure of core/spm > > > > Hi, > > > > Several patches for code restructure is coming. Before I post the > > gerrit items, I want to collect your feedback on this. These changes contain: > > > > - Move header files into dedicated directory for easy include, and > > clean the included headers in sources; > > - Change some files' name to let them make more sense. > > - Move SPM related files into 'spm' folder instead of putting them in 'core'. > > - Move some interface files into 'ns_callable' since they are interfaces. > > - Remove 'ipc' folder after all files in it are well arranged. > > > > I will try to do these patches together so they can be merged together. > > But before that I want to request for comments about this, feel free > > to reply in this thread or comment on the task (add yourself if you > > are missing as > > subscribers): > > https://developer.trustedfirmware.org/T426 > > > > BR > > > > /Ken > > > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Andrew Thoelke

Hi Reinhard & Ken, There are definitely some challenging trade-offs, and the right approach can depend on the system and use case. PSA Firmware Framework is a architectural interface design for deployment on different CPU/SoC designs, and defines an interrupt framework that: 1. can be implemented on these different architectures 2. is aligned with the security & isolation principles of the Framework PSA-FF does not stop an implementation (such as TF-M) from providing additional interrupt frameworks that provide lower-latency for some components. These will obviously be non-portable (to other PSA-FF implementations) and may have security trade-offs if the ISR runs in a privileged secure state to achieve performance requirements. As you suggest, although it is possible to discuss the options in general - it is only possible to make good design decisions with real use cases for integrating hardware devices into the secure side of the system, and the required behaviour of the interrupt handlers. There is a substantial evidence that weakening the isolation requirements is not typically balanced by keeping the critical code simple, reviewed and secure - based on the experience of TrustZone and other TEE software implementations. I agree that such careful code development is possible, but it is not normal (at the moment). Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 18 December 2019 13:49 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Ken, thanks for the reply. My take on that is that instead of adding overhead to ISR, ISR should be executed fast. For ISRs we should publish clear guidelines that explain potential side effects of ISR execution. These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution. How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available. What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway. Reinhard 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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai

Hi Matt, Sorry not to review your patch as soon as possible because you forget adding me to the reviewer list😊 I had reviewed it now. By the way, there is a contributing process in TF-M which require to create a related ‘task’ for task management. I had helped to create one for this issue. Please help to create it the next time. I can help you if you have any problems with it. For more detail, you can refer to this:https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/proce…, Hi All, Here is the patch link: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2923. Please help to review it Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M Sent: Friday, December 20, 2019 12:49 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, If it is a bug, I will upsteam a patch to fix it later. Thanks, Matt

5 years, 4 months

1
0
0 0

IRQ: use defined name from platform

by Alamy Liu

Hi all, There are new platforms (cypress/psoc64/ & sse-200_aws), and I update the patch to includes the two new platforms. Please help on reviewing. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2687/ Thanks, Alamy

5 years, 4 months

1
0
0 0

19th December TF-M Technical Forum call - slides and video

by Bill Fletcher

These are now available at: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 4 months

1
0
0 0

User guide doc about how to add a Secure Partition

by Edison Ai

Hi all, There are many people had asked that is there a user guide document about how to add a Secure Partition in TF-M? Now, here is it: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2921/. Please help to review it.😊 Thanks, Edison

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Matt

Hi Edison, If it is a bug, I will upsteam a patch to fix it later. Thanks, Matt At 2019-12-19 16:43:18, "Edison Ai via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Sorry not got your point in the first time. Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example. Can you upstream a patch to fix it? Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Wednesday, December 18, 2019 9:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, | interrupted_ctx_stack_frame_t | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t (used) | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.” Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: | SP2 stack pointer -à | | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. | SP2 stack pointer -à | Partition_state(interrupted) | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To:tf-m@lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

5 years, 4 months

1
0
0 0

New blog post: Trusted Firmware at Lyon.

by Augustina Adjei

Hello, We have a new blog post detailing TF-M in Lyon here: https://www.trustedfirmware.org/blog/trusted_firmware_at_lyon/ Thank you, Augustina Adjei [cid:image001.jpg@01D5B688.34C152B0] Mawuelome - Seyram Augustina Adjei Central Engineering - Open Source Software Group augustina.adjei(a)arm.com 110 Fulbourn Road, Cambridge, CB1 9NJ www.arm.com<http://www.arm.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.

5 years, 4 months

1
0
0 0

Trusted Firmware-M CI-Trigger Behavior change notification

by Minos Galanakis

Hi all, The triggering behavior of the Trusted Firmware-M CI has been adjusted. Tests jobs will no longer trigger automatically. Instead when the patch submitter would like their code to be tested, they will need to assert the newly introduced `Allow-CI` Gerrit voting flag. Regards Minos

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - 19th December

by Anton Komlev

Because of New Year holidays, the next forum is planned on Jan 9, 2020. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: 19 December 2019 02:37 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - 19th December Update the Agenda: (added TF-M profile session) - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - [RFC] TF-M Profile - Cryptocell integration Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, December 13, 2019 2:14 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - 19th December Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai

Hi Matt, Sorry not got your point in the first time. Yes, you are right. It is indeed a bug here. And thanks for your detail explaining and good example. Can you upstream a patch to fix it? Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Wednesday, December 18, 2019 9:54 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] irq handling in library mode Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, interrupted_ctx_stack_frame_t handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, interrupted_ctx_stack_frame_t (used) handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, interrupted_ctx_stack_frame_t (used) handler_ctx_stack_frame_t (used) interrupted_ctx_stack_frame_t ... handler_ctx_stack_frame_t interrupted_ctx_stack_frame_t Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm<file://(Arm> Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location." Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: * SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: SP2 stack pointer ---> Caller_partition_indx(handler) Partition_sate(handler) * SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. SP2 stack pointer ---> Partition_state(interrupted) Caller_partition_indx(handler) Partition_sate(handler) And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - 19th December

by David Wang

Update the Agenda: (added TF-M profile session) - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - [RFC] TF-M Profile - Cryptocell integration Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Friday, December 13, 2019 2:14 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - 19th December Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by lg

Hi Edison, Thanks for your reply. In file tfm_secure_irq_handling.rst, we can know every SP have a continuous irq related stack as follows, | interrupted_ctx_stack_frame_t | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | And this stack pointer is saved in the field ctx_stack_ptr of structure spm_partition_runtime_data_t for each partition. If partition A is interrupted for the first time by a lower priority interrupt, as current code shown bellow, the interrupted_ctx_stack_frame_t will be pushed at the beginning of the irq stack. void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } Now the stack is show as below, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | But the stack pointer is not moved upper after pushing interrupted_ctx_stack_frame_t, so the ctx_stack_ptr is still point to the beginning of the stack. At this time,if a higher priority interrupt of partition A is coming, partition A becomes handler partition, so the structure handler_ctx_stack_frame_t should be pushed in the stack of partition A, as current code shown below, void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } As it shown above, the content of handler_ctx_stack_frame_t will be overlapped with already pushed content of interrupted_ctx_stack_frame_t. My question is exactly about the above scenario. If the stack pointer is also moved upper after pushing the interrupted_ctx_stack_frame_t, handler_ctx_stack_frame_t will be pushed at different location in the stack as follows, | interrupted_ctx_stack_frame_t (used) | | handler_ctx_stack_frame_t (used) | | interrupted_ctx_stack_frame_t | | ... | | handler_ctx_stack_frame_t | | interrupted_ctx_stack_frame_t | Please read the file tfm_secure_irq_handling.rst again , and help to check about this question. Thanks, Matt At 2019-12-17 14:22:13, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: “If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location.” Let’s start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: | SP2 stack pointer -à | | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. | SP2 stack pointer -à | Partition_state(interrupted) | | | Caller_partition_indx(handler) | | | Partition_sate(handler) | And after SP2 is interrupted by SP3, its partition status will be changed to “SPM_PARTITION_STATE_SUSPENDED”. So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

5 years, 4 months

1
0
0 0

irq handling in library mode

by Reinhard Keil

Ken, thanks for the reply. My take on that is that instead of adding overhead to ISR, ISR should be executed fast. For ISRs we should publish clear guidelines that explain potential side effects of ISR execution. These guidelines should advocate that ISR is kept short, and workload is off-loaded to thread execution. How this is exactly done in secure side needs to be defined, as the RTOS (on non-secure side) might inconsistent and not be available. What would be really good is to have typical ISR routines that execute in secure side. This would better allow us to judge what is really needed. I believe most of them are small anyway. Reinhard 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.

5 years, 4 months

1
0
0 0

Level 2/Level 3 Isolation requires IPC?

by Reinhard Keil

Ken thanks for your answer. So it is up to the PSA Framework team to define the right framework? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] Adding a new test partition to test multi-partition scenarios

by Andrej Butok

We already have about 7 test services/partitions. It's growing. To save resources. Is it possible to combine the test partitions to one or just few? From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: Wednesday, December 18, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Adding a new test partition to test multi-partition scenarios Hi all, There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys. Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution. I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features. Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> Kind regards, Jamie

5 years, 4 months

2
1
0 0

Adding a new test partition to test multi-partition scenarios

by Jamie Fox

Hi all, There's a need to test service features in TF-M involving more than one partition taking certain actions. For example, the ITS service implements access control for assets in storage based on the partition ID of the client, so we want to test the case where one partition attempts to access an asset belonging to another. There is a similar scenario for Crypto involving access control for keys. Previously we have tested the same feature in SST with multiple NS RTOS threads, relying on the NS RTOS to provide distinct client IDs for each, but as NS client identification may not always be available this is not the ideal solution. I am proposing we add a 'Secure Client 2' test partition to act as slave for the Secure Client (1) test partition that executes the secure test suites. The new partition provides a service to call test functions by ID within its execution context and return the resulting status to the caller. The initial implementation is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2838 . For now it is as simple as possible, just provides one API to call functions by ID, no support for passing other arguments, but we can extend when there is a need for more features. Here I have implemented a basic test for ITS access control using the new partition: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2790 Kind regards, Jamie

5 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Gyorgy Szing

Hi, "... with 80 column while reviewing (not put this into document) ... " FIY our coding standard explicitly requires 80 chars limit for C code. (See: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… ) /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 18 December 2019 02:04 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles. But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review. For services, I won't propose specified limits because some of them may be external projects which is hard to be limited. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 18, 2019 12:40 AM To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

2
1
0 0

Re: [TF-M] Level 2/Level 3 Isolation requires IPC?

by Ken Liu

Hi Reinhard, This is correct at current and needs SFC specification to clarification in future. The existing PSA Firmware Framework proposes a thread based Secure Partition and the IPC manner about how the information is shared between these process. The SFC model (which is a well know model but do not have a specification yet) combines secure services as a library and makes the information-sharing mechanism complicate under isolation level 2/3, which lost the advantage of 'library' model. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, December 17, 2019 4:10 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Level 2/Level 3 Isolation requires IPC? I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode. It does not work with Secure Function Call (SFC) mode (aka Library mode). Is it correct, and why does Level2/Level 3 isolation require IPC? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Ken Liu

Hi Reinhard, Your approach is good for a RTOS. For secure firmware, we need to: * A secure partition may bind an interrupt in its manifest, which means the interrupt related logic of a secure partition should be inside secure partition's scope. (This is what the library model is doing.) * To avoid affect non-secure RTOS execution, IRQ should be quick and heavy execution can be delay into secure partition thread. (This is what IPC model is doing). This interrupt handling is keeping evolution, we are trying to create a proposal to provide: * Fast ISR execution. * Put non-urgent interrupt related logic into thread. Now we are collecting proposals and your comment is an important input. And I think the DMA part needs to be considerate much as you have mentioned, it may bypass MPU. If anyone is also working on this topic, please send mail in this mailing list or create an issue (developer.trustedfirmware.org). Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, December 17, 2019 4:04 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] irq handling in library mode I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational: * IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects. * IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC. Another reason of this relaxed approach is the usage of DMA. * DMA is frequently controlled by IRQ * DMA also bypasses MPU, therefore same behaviour as IRQ. Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core. What is wrong with that approach? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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. 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.

5 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Ken Liu

Hi, For me both 100 or 80 are acceptable for c sources, and no limit for scripts/makefiles. But at current I am trying to limit the core/spm source with 80 column while reviewing (not put this into document) because it works well under default gerrit setting and easies the review. For services, I won't propose specified limits because some of them may be external projects which is hard to be limited. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 18, 2019 12:40 AM To: David Brown <david.brown(a)linaro.org>; Reinhard Keil <Reinhard.Keil(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Coding guideline Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by Gyorgy Szing

Hi, One limit we have to regularly face is imposed by the gerrit diff view (i.e: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/… ). It might be worth to check how many characters do fit the half of the view on a full-hd monitor with default font size settings in modern browsers (chrome, firefox, etc..). (In my environment the limit seems to be around 100.) Of course unified view may help (i.e. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2560/6/bl2/ext/…), but we should try to avoid limiting UI usage as much as possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Brown via TF-M Sent: 17 December 2019 17:17 To: Reinhard Keil <Reinhard.Keil(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors > – it comes from the teletype time where 80 characters was the natural > limit on CRT or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] Coding guideline

by David Brown

On Tue, Dec 17, 2019 at 08:58:13AM +0000, Reinhard Keil via TF-M wrote: > IMHO a 80-char restriction is irrelevant with today’s screens/editors – it > comes from the teletype time where 80 characters was the natural limit on CRT > or punch card. I do tend to agree to this. I still think it is useful to have a limit, but something like 100 or even 120 makes a lot more sense. However, even though we have bigger screens, it is still useful to have multiple smaller terminal windows rather than just one big one. But, for myself, I tend to always have them at least be 100 characters. David

5 years, 4 months

1
0
0 0

T398/T413: Source cleanup and tool integration

by Thomas Törnblom

I have just pushed the latest commits for the source cleanup and IAR integration. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2831 Please review. Thanks, Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 19 Dec 2019 07:00 - 08:00 (GMT) (tf-m@lists.trustedfirmware.org)

by bill.fletcher＠linaro.org

You have been invited to the following event. 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.Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings.Initially we propose a bi-weekly call and then we'll change cadence depending on interest Feel free to forward it to colleagues.──────────Bill Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+17207072699,,5810428000# US (Denver)Dial by your location +1 646 558 8656 US (New York) +1 720 707 2699 US (Denver) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 19 Dec 2019 07:00 – 08:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MnVjODY4YmlscGlxbHU2b… Invitation from Google Calendar: https://www.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://www.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 organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 4 months

1
0
0 0

Coding guideline

by Reinhard Keil

Has there been any conclusion on coding guidelines. IMHO a 80-char restriction is irrelevant with today's screens/editors - it comes from the teletype time where 80 characters was the natural limit on CRT or punch card. MISRA in contrast is industry standard and a fundamental requirement in many projects. What is the progress here? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 5 months

1
0
0 0

Level 2/Level 3 Isolation requires IPC?

by Reinhard Keil

I have heard that Level 2/Level 3 isolation with TF-M requires Inter-Process Communication (IPC) mode. It does not work with Secure Function Call (SFC) mode (aka Library mode). Is it correct, and why does Level2/Level 3 isolation require IPC? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Reinhard Keil

I would argue that "IRQ handling" should just be standard v8M hardware behaviour for the following rational: * IRQ routines should be short and simple by nature - it is therefore relative easy to fully verify it and ensure that there are no side effects. * IRQ should be therefore executed in handler mode using MSP, no MPU protection, only protection via SAU, PPC, MPC. Another reason of this relaxed approach is the usage of DMA. * DMA is frequently controlled by IRQ * DMA also bypasses MPU, therefore same behaviour as IRQ. Overall this approach ensures simple, fast IRQ execution (sales argument of v8M) and reduces risk software glitches in TF-M Core. What is wrong with that approach? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I will be collecting for new review comments till this Friday. If there were no new comments, I will get the patches merged after addressing the existing comments. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:02 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Support for optional build for secure partitions and test suites Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] irq handling in library mode

by Edison Ai (Arm Technology China)

Hi Matt, Thanks for your email. Let me try to answer your question because of the designer of the TF-M interrupt handling is on leave now. First, you are right about this: "If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location." Let's start from an example, there are 3 SPs with different interrupt priority, SP1 < SP2 < SP3. And there is one scenario like this: * SP1 is running, SP2 interrupt SP1. Current, the interrupted partition is SP1, and the handler partition is SP2. As the below code show in tfm_spm_partition_push_handler_ctx(), the stack pointer will be moved upper as below: SP2 stack pointer ---> Caller_partition_indx(handler) Partition_sate(handler) * SP2 starts to run, and it is interrupted by SP3. Current, the interrupted partition is SP2, and the handler partition is SP3. As the code shown in tfm_spm_partition_push_interrupted_ctx(), it uses the current stack member directly without moving its pointer. SP2 stack pointer ---> Partition_state(interrupted) Caller_partition_indx(handler) Partition_sate(handler) And after SP2 is interrupted by SP3, its partition status will be changed to "SPM_PARTITION_STATE_SUSPENDED". So that this partition will not be interrupted by others anymore unless it comes back to running state. Which means it does not need more stack anymore. We can consider that after one SP is interrupted by others, there is no more stack is needed for it before it comes back to running status. So I think it should be ok in the current design for the interrupt in the library model. I am not sure if this can solve your confuse. Please feel free to give feedback. We can discuss more about it. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Monday, December 16, 2019 1:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] irq handling in library mode Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

5 years, 5 months

1
0
0 0

Re: [TF-M] MPU issues, was Re: Regression test issues with IAR port

by Edison Ai (Arm Technology China)

Hi Thomas, What I can see from your description is that the problem should is caused the MPU configure. You are working on the isolation level 2 model by using ConfigRegressionIPCTfmLevel2 configure file. In isolation level 2, PSA FF says this: "the PSA Root of Trust is also protected from access by the Application Root of Trust". You can see more detail about the isolation information from PSA FF with this link: https://pages.arm.com/psa-resources-ff.html?_ga=2.156169596.61580709.154261…. So, we need to configure MPU(MSUCA_A board which you are using) for APP RoT to limit the source the APP RoT can access in isolation level 2. You can see from code: __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } The psa_wait() is put in the "SFN" region, and the "SFN" region in put in the "TFM_UNPRIV_CODE" section. You can see the information about the "TFM_UNPRIV_CODE" in platform/ext/common/armclang/tfm_common_s.sct. You can refer tfm_spm_mpu_init() in platfrom/ext/target/musca_a/spm_hal.c. There are some MPU region we need to configure for APP RoT in isolation level 2, include the "TFM_UNPRIV_CODE". If you are interested, you can see some detail about the design of isolation level 2 from here: https://developer.trustedfirmware.org/w/tf_m/design/trusted_firmware-m_isol… Please check this first. If cannot work, please feel free to tell us. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, December 13, 2019 4:25 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] MPU issues, was Re: Regression test issues with IAR port Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 5 months

2
2
0 0

irq handling in library mode

by lg

Hi TFM experts, I have a question about the code logic of irq handling in library mode, code blocks in spm_api_func.c are as follows: void tfm_spm_partition_push_interrupted_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct interrupted_ctx_stack_frame_t *stack_frame = (struct interrupted_ctx_stack_frame_t *)runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; } void tfm_spm_partition_push_handler_ctx(uint32_t partition_idx) { struct spm_partition_runtime_data_t *runtime_data = &g_spm_partition_db.partitions[partition_idx].runtime_data; struct handler_ctx_stack_frame_t *stack_frame = (struct handler_ctx_stack_frame_t *) runtime_data->ctx_stack_ptr; stack_frame->partition_state = runtime_data->partition_state; stack_frame->caller_partition_idx = runtime_data->caller_partition_idx; runtime_data->ctx_stack_ptr += sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); } My question is why there is not the following such code logic at the end of function tfm_spm_partition_push_interrupted_ctx. runtime_data->ctx_stack_ptr += sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); If the interrupted partition is the same as the handler partition, interrupted_ctx_stack_frame_t and handler_ctx_stack_frame_t should be pushed at different location. And when pop the stack frame after handling irq, there is the following code logic in tfm_spm_partition_pop_handler_ctx runtime_data->ctx_stack_ptr -= sizeof(struct handler_ctx_stack_frame_t) / sizeof(uint32_t); I think the same logic of changing ctx_stack_ptr should be added the begining of the function tfm_spm_partition_pop_interrupted_ctx like the above code logic in tfm_spm_partition_pop_handler_ctx. runtime_data->ctx_stack_ptr -= sizeof(struct interrupted_ctx_stack_frame_t ) / sizeof(uint32_t); Please help to check. Thanks, Matt

5 years, 5 months

1
0
0 0

Re: [TF-M] Adding Cypress PSoC64 platform support

by David Hu (Arm Technology China)

Hi all, After several rounds of review, I'd like to merge Cypress PSoC 64 support on master branch this Tuesday. If you have more comments or opinions, please share them before Tuesday. Thank you. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Saturday, December 7, 2019 4:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Adding Cypress PSoC64 platform support Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I'd like to merge the patch set https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… soon if no further comments. Please share your comments before this Tuesday. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, December 12, 2019 11:57 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the patch set to extract duplicated template files from platforms Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by David Wang (Arm Technology China)

The current RTOS integration with TZ API support is to make it generic. You can use "empty" implementation for these API if you don't use multiple secure context (SFC or IPC model) and have no multiple NS client IDs requirements. Besides that, the users can leverage TZ API for some other purposes, e.g. policy control for which NS task can access which secure partitions and etc. But that's quite use case specific. Just FYI. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 19:41 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) Ken, thanks for all your swift answers. Sorry, I need to check on this part of the answer again: * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Ken.L: If there is no locking protection in NS and multiple ns calling would panic. TZ RTOS Context Management does not prevent from that. Correct. So the only feature that is enabled with TZ RTOS Context Management is 'client ID identification' for Protected Storage (and potentially other services). Reinhard 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Hi, I agree, the CI shall not dictate how we use the version control system. It shall adapt. Regarding your suggestions, I think the main problem is we are mixing stuff, this time quality with version control. Before we make decisions we shall understand where we are. The current quality policy is that we only make releases for communication purposes. To give a clean interface for tf-m users and to allow planning their work. Releases allow them to execute their tf-m integration process less frequently. Only for each release or specific releases and not for each commit. The current quality policy identifies a single quality level only, and says any patch we publish is "golden quality", it matches the highest quality standard we can achieve (with sane constraints). Also to make our life easy we decided to use the master branch to hold these patches. At the same time we use the master branch for development. Any change we make is made against master. This means each pull request and thus each review targets master. For review purposes the best is to have a chain of small modifications, otherwise the review content becomes too large to follow. The TF-A "branching strategy" tries to address this issue by introducing an integration branch used for development. This allows master to be more release specific. I suggest to take the following approach (details to be discussed): - introduce more quality levels i.e.: - none: content of a topic branch, or content pushed to review. - bronze: content passed code review and patch specific testing. - silver: content passed a more though daily testing. - gold: a release. A pack of source-code, feature state document (release notes), reviewed documentation (user manual, reference manual), test evidence, documentation of test efforts to allow repeatability. The version control system can be used to store content, and to provide identification info (i.e. tagging), but most likely the release will need other kind of storage to be used (i.e. documentation). - platina: reaching extra quality level trough passing PSA or some FUSA qualification. Or we may simply use extra release for this. Naming the quality levels allows us to have a cleaner definition of what can be expected at a specific level (set of quality measures, i.e. static analysis, code review, test configuration). It would also allow us cleaner communication and to find how we use the version system for quality purposes. I also expect this discussion to help defining how the version system is used for development purposes. The current state works ok, but is a sort of naturally grown. We might have reached the point when more pragmatic approach may be needed. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 13 December 2019 12:23 To: Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org>; Soby Mathew <Soby.Mathew(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

Ken, thanks for all your swift answers. Sorry, I need to check on this part of the answer again: * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Ken.L: If there is no locking protection in NS and multiple ns calling would panic. TZ RTOS Context Management does not prevent from that. Correct. So the only feature that is enabled with TZ RTOS Context Management is 'client ID identification' for Protected Storage (and potentially other services). Reinhard 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Minos Galanakis

Hi all. My personal comments on this. I would like to point out that the CI is a tool, not the core project. I do not believe we should be changing our development strategy based on what the tool is doing. We should instead adjust the tool to fit our requirements. * No patches should be/ are merged to master when CI fails. If master breaks it should most commonly be because of something we are not testing for. Using an integration branch would not change that. * As a developer I find it more convoluted to work with projects who use different integration strategies. The most common assumption in open source projects is that you have a master branch which is the bleeding edge, but can contain untested bugs, and the release immutable git tags for versioning. Using branch merges as versioning is a design for the pull request model which is not quite compatible with Gerrit. * Most of the CI downtime has nothing to do with the merge strategy, they are more of a chicken and the egg philosophical problem. If your patch or branch introduced a change which affects the tests outputs, how will you test it if the CI expects the old output? An integration branch would not solve the merge freeze periods, would just affect a different branch from master. * I believe feature branches are quite useful, since changes to master do not disrupt the development flow of a big change, and even though they will require some maintenance to re-sync before the final patch , it will be handled by an engineer who knows the feature, and full understands the regression vectors. If I were to suggest some changes for stability purposes, I would start smaller: * Update documentation to instruct users to check out from release tags, warning then that master is constantly changing. * Adjust the CI to detect an Allow-CI flag from every branch. That way developers can test any patch from any feature branch. The logic for that is already present in the code, but requires Gerrit to be configured accordingly. * Add an undo process. This would be the only case for an integration branch. All patches are merged to a temporary branch, after confirming they have passed testing individually. On the once per day nightly test, the group of different patches, will be tested against an extensive job, in models and hardware, and only if successful it will fast forward master to that state. Regards Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 13 December 2019 08:55 To: Soby Mathew <Soby.Mathew(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Soby, Thanks for your detail description. > Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. > This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. I think it's a good method like this so that we can double confirm the "master" branch is stable. And this also can fix one case even the CI can work normally: one patch is ready to merge, and it is not based on the latest HEAD, but there is no conflict. We can merge the patch directly and let gerrit do rebase by itself. But we cannot confirm the CI test can pass. Any comment for this from others? For multiple feature branches, I think we can stop to discuss about it now until we have some strong demands for it. It is indeed a big change for us now. Thanks, Edison -----Original Message----- From: Soby Mathew <Soby.Mathew(a)arm.com> Sent: Friday, December 13, 2019 5:14 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

Ken, Thanks for your reply. Let me summarize what I have understood: TF-M SFC mode: * Allows only one thread at the time to call secure services. * When secure services are called recursively (multiple threads) TF-M goes into 'panic' state. This should not happen with proper mutex locks. * TZ RTOS Context Management interface is only required when "Client Oriented Policy" is used. I have updated the diagram to reflect what I have understood. Obviously the SVC would be only executed when the call into "secure" is from Thread mode. Is my understanding correct? (diagram is also under: https://developer.trustedfirmware.org/T615) - I just realized that you made a similar picture). [cid:image003.jpg@01D5B197.BE352670] The initial question can be then refined to: * TZ RTOS Context management is only needed when "Client Oriented Policy" is used. * When and why is "Client Oriented Policy" a requirement on v8-M systems? * Is there a way to disable ""Client Oriented Policy" in the current TF-M Core? * This applies for both the TF-M firmware itself and the related test suite. * What happens worst case when an RTOS does not implement TZ RTOS Context Management? Reinhard _______________________________________________________________________________ Reinhard Keil | Phone: +49 89 456040-13 | Email: reinhard.keil(a)arm.com<mailto:reinhard.keil@arm.com> | www.keil.com<http://www.keil.com> ARM Germany GmbH | Bretonischer Ring 16 | D-85630 Grasbrunn,Germany Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) Geschäftsführer: Andrew Smith, Joachim Krech, Reinhard Keil 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.

5 years, 5 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks for your quick patch. Hi All, The patch link is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2792/. Please help to review it if you are interested. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 4:42 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Secure storage and Internal trusted storage code logic check Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Soby Mathew

On 11/12/2019 09:05, Edison Ai (Arm Technology China) via TF-M wrote: > Hi Gyorgy, > > Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. > There are three branches in TF-A: > - "integration" branch, should be used for new features. > - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. Hi Edison, Integration is a temporary merge branch to merge several patches and run the CI against. Usually once CI passes, the master will be fast forwarded to integration within a day. This helps us to test integration of patches and detect any failure before master is updated. This means the master will pass CI at any given merge point. > - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. > @Soby Mathew Could you help to share more information about it? Thanks very much. We usually do not have feature branches in TF-A. The topics/epic_beta0_spmd is a prototyping branch where we wanted to share code with collaborators outside TF-A. The patches on this branch are not visible in gerrit review and no patches in gerrit review will be merged to this branch. Once the prototyping is complete, then patches on this branch will be reworked and pushed to gerrit review and finally get merged to integration and this branch will be deleted. Our experience have been, long running development branches are generally a maintenance overhead. Merging these development branches before a release may also be risky as some of the changes may have unknown interactions and may become difficult to resolve. The "topic" in gerrit review is effectively a branch. For example, this review: https://review.trustedfirmware.org/#/q/topic:od/debugfs+(status:open+OR+sta… is a set of patches on topic "od/debugfs" and can be treated as development branch. This branch is alive as long as patches are not merged. We need to understand the motivations for the change. Broken CI is an argument but development branches will only exacerbate that problem since we don't know the stability of each of those branches. Also merge conflict will not reduce due to development branches. Its just delaying the merge conflict to a later point. There may be other reasons, but generally it is better to merge sensible patches (+2ed) within a feature even before the feature is complete as it will reduce merge conflicts (we have to ensure testing/build coverage for the patch). These are my thoughts on this. Best Regards Soby Mathew

5 years, 5 months

2
1
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Ken Liu (Arm Technology China)

Hi Reinhard, Guess this diagram for a long time ago design since the latest version there is no need for NS SVC. (Check diagram attached in the ticket). I think the existing library model implementation is almost the one you described, just some points: - We use a secure SVC in SPM for sanitization input/output buffers. - We do secure partition maintenance in SPM (forward call, maintain state). The TZ API implementation under SFC is for the purpose that some services have bound the client with policies so they need to know which client is calling. It can be skipped if there is no such client-orient policy. And one thing to mention, even we propose to use locks in RTOS for locking the interface, there would be a chance that some RTOS has a limitation on these lock APIs, or someone just acts as an attacker who skips the necessary locking operations, then we need to provide some detection in the secure side as countermeasures, and this part needs to be documented to remind users that, please make sure there is only one ongoing secure call or a panic is generated. Then it would be RTOS' choice to decide if they want to avoid this panic by locking. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, December 12, 2019 11:22 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution) As the picture got lost, I did create also https://developer.trustedfirmware.org/T615 This contains the picture Reinhard 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

MPU issues, was Re: Regression test issues with IAR port

by Thomas Törnblom

Next issue. For some reason the secure image runs into a MemManage exception fairly early in the irq test of the ConfigRegressionIPCTfmLevel2 config and I have not yet been able to figure out why. It happens in the psa_wait() call in: --- int32_t tfm_irq_test_1_init(void) { tfm_enable_irq(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ); #ifdef TFM_PSA_API psa_signal_t signals = 0; while (1) { signals = psa_wait(PSA_WAIT_ANY, PSA_BLOCK); --- The exact point of the exception is the SVC call in: --- __attribute__((naked, section("SFN"))) psa_signal_t psa_wait(psa_signal_t signal_mask, uint32_t timeout) { __ASM volatile("SVC %0 \n" "BX LR \n" : : "I" (TFM_SVC_PSA_WAIT)); } --- The cause is IACCVIOL, "The processor attempted an instruction fetch from a location that does not permit execution." The stack frame indicates that it happened on the SVC instruction, but I as far as I can see none of the MPU regions maps the address so I assumed it should be allowed as it should be handled by the background map, which should allow secure access. If I don't enable the mpu (just skipping the enable call) then all tests run without problems. I have tried to compare it with an image built with ARMCLANG, and I don't see anything obviously different. The regions are roughly the same, all regions with fixed addresses are the same, the enable bits are the same and the SVC handler is not mapped to any MPU region there either. I wish there were an MPU status register that would tell exactly what region was causing the exception. The odd thing is that there is an SVC call in the tfm_enable_irq() call prior to the psa_wait() call, and that works. This is on a Musca A by the way. Ideas? -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

TF-M Technical Forum call - 19th December

by Anton Komlev

Hello, To continuing our open discussion, started a week ago let me propose the 2nd session and create this mail thread to discuss related topics. 1. The time slot. Looking on participants' distribution [Asia:6, Europe:20, US East:1, US Cent:1, US West:4, Total:32] I see the majority is in Europe. The Asian region could be more presented giving a more comfortable time. Having this in mind, I would propose to have the 2nd session on Dec 19 at 7:00 UTC time. This compromise gives US West coast a chance to join at 23:00 (Dec 18!). Here is the summary: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=… Please share your thoughts and alternatives. The related question: shall we fix the time or rotating? You can play with the time slot here: https://www.timeanddate.com/worldclock/meetingtime.html?day=19&month=12&yea… 2. Agenda as a proposal - The interrupts' topic was followed by email and looks like closed. Are there remaining points for discussion? - TF-M and Amazon FreeRTOS integration update - Cryptocell integration - ? Best regards, Anton Komlev

5 years, 5 months

1
0
0 0

Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

by Gyorgy Szing

Hi, Sorry the image did not got trough. One way to share the image could be to create a ticket here https://developer.trustedfirmware.org/maniphest/ where the image can be uploaded. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 12 December 2019 13:13 To: tf-m(a)lists.trustedfirmware.org Cc: Bruno Mendes <Bruno.Mendes(a)arm.com> Subject: [TF-M] Simplify RTOS / TF-M interface (single thread execution) When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Simplify RTOS / TF-M interface (single thread execution)

by Reinhard Keil

When using TF-M on v8-M with Secure Function Call SFC (aka Library) mode, the entry to the secure side is protected by a Mutex. Thus only one thread at the time is calling a secure service. The picture below should therefore represent the execution flow (Level 1 isolation). [cid:image003.jpg@01D5B0ED.DEEA6A60] Under this assumption there is no need to implement TZ_context management in the RTOS (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…). Any RTOS could be used, provided that the Mutex capability is sufficient. Moreover this design should create a really simple secure side: * Only one stack is needed on the secure side for Thread mode execution * No multi-threading issues that need to be resolved (i.e. with access of hardware crypto accelerators) The drawback of course is that only one task at a time can use a secure service. However an RTOS with priority inversion will ensure that the Secure service is executed as fast as possible, once a scheduling conflict arises. I would like to gather feedback on that approach. Let me know what you think. Reinhard 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by DeMars, Alan

Ken, Task scheduling (context switching) in our RTOS is always performed in thread mode, even when asynchronous pre-emption occurs resulting from an ISR readying a higher priority task. All kernel-managed interrupts are routed to a common interrupt dispatcher that, just prior to returning from an interrupt, will invoke the task scheduler when it determines that there are no more interrupts pending and there is scheduling work to do. In that case, an artificial interrupt context is created so that thread mode can be "returned to" from handler mode. The task scheduler is then invoked in thread mode from the stack of the pre-empted task. Regarding secure interrupts, our use cases only employ secure interrupts as a consequence of a psa_call() initiating a process that completes when an interrupt goes off sometime later. Rather than spin-waiting for the interrupt-completion signal, or parking in a WFI, we simply return from the psa_call() with a special return code indicating that the process has started and that the calling thread will be notified of completion by the secure callback mechanism I described at the conference in Lyon. The calling thread then pends on a semaphore. When the secure interrupt goes off later on, a dedicated non-secure interrupt is triggered that ultimately ends up posting the semaphore that the NS thread is pended on. Upon returning from the pend, the NS thread then re-enters the SP (using psa_call()) to complete the transaction. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, December 10, 2019 8:04 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Secure Interrupt handling - RE: TF-M technical Forum slides and recording Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by lg

Hi Edison, Thanks for your quick reply. I will try to upstream a patch later. Thanks, Matt At 2019-12-12 11:15:51, "Edison Ai \$Arm Technology China\$ via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: >Hi Matt, > >Thanks very much for your mail. It looks like it is indeed a problem here. >Can you upstream a patch to help to fix them directly? > >Thanks, >Edison > >-----Original Message----- >From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M >Sent: Thursday, December 12, 2019 9:43 AM >To: tf-m(a)lists.trustedfirmware.org >Subject: [TF-M] Secure storage and Internal trusted storage code logic check > >Hi TFM Secure storage & Internal trusted storage experts, > > > It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. > There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: > > > for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i); > } > This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. > If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START > is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. > Should it be the following logic? > > > for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { > /* If a flash error is detected, the code erases the rest > * of the blocks anyway to remove all data stored in them. > */ > err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); > } > It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. > > > Please help to check. > > >Thanks. >Matt. > >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m >-- >TF-M mailing list >TF-M(a)lists.trustedfirmware.org >https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Please review the patch set to extract duplicated template files from platforms

by David Hu (Arm Technology China)

Hi all, I submit a patch set to extract the duplicated identical template files dummy_xxx.c from targets and put them under platform/ext/common/template folder. The purpose is to collect a common template of booting/attestation example for platforms and each platform doesn't need to keep a copy under its folder anymore. Since it is a general change related to all platforms using template files, I'd like to ask for review here. Any comments would be appreciated. Please check the patch details in https://review.trustedfirmware.org/q/topic:%22template_plat_files%22+(statu… The background is described in https://developer.trustedfirmware.org/T539. Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] Secure storage and Internal trusted storage code logic check

by Edison Ai (Arm Technology China)

Hi Matt, Thanks very much for your mail. It looks like it is indeed a problem here. Can you upstream a patch to help to fix them directly? Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of lg via TF-M Sent: Thursday, December 12, 2019 9:43 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Secure storage and Internal trusted storage code logic check Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Secure storage and Internal trusted storage code logic check

by lg

Hi TFM Secure storage & Internal trusted storage experts, It seems there are code logic errors in both files sst_flash_fs_mblock.c and its_flash_fs_mblock.c. There are following codes in function its_flash_fs_mblock_reset_metablock in its_flash_fs_mblock.c: for (i = ITS_INIT_DBLOCK_START; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i); } This loop starts from ITS_INIT_DBLOCK_START and ends to ITS_NUM_DEDICATED_DBLOCKS. If there are four ITS blocks including meta blocks and data blocks in all, that means ITS_INIT_DBLOCK_START is 3 and ITS_NUM_DEDICATED_DBLOCKS is 1. But the above loop can not erase the data block any way. Should it be the following logic? for (i = 0; i < ITS_NUM_DEDICATED_DBLOCKS; i++) { /* If a flash error is detected, the code erases the rest * of the blocks anyway to remove all data stored in them. */ err |= its_flash_erase_block(i+ITS_INIT_DBLOCK_START); } It is the same logic in function sst_flash_fs_mblock_reset_metablock in file sst_flash_fs_mblock.c. Please help to check. Thanks. Matt.

5 years, 5 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Ken Liu (Arm Technology China)

Thanks Thomas. Let me try that link. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, December 11, 2019 9:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IAR libc behavior? Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] IAR libc behavior?

by Thomas Törnblom

Hi Ken, There should be no difference from GNUARM or ARMCLANG in this respect. Should not need any special switches. If you wish to try out our tools, you can download a trial version until we have arranged for a permanent solution, see: https://www.iar.com/iar-embedded-workbench/#!?architecture=Arm Cheers, Thomas Den 2019-12-11 kl. 11:05, skrev Ken Liu (Arm Technology China) via TF-M: > Hi Thomas, > > I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. > If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? > > Thanks. > > /Ken -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

IAR libc behavior?

by Ken Liu (Arm Technology China)

Hi Thomas, I have a question about IAR compiler since we verify default GNUARM and ARMCLANG in the existing sources. If we are trying to implementing some internal version of libc APIs like 'memcmp', would IAR link with this implemented version first, or it just report a link error of duplicated symbol? Any switches do we need to assign to support this? Thanks. /Ken

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi Gyorgy, Thanks to point it out. I agree with you that it will be better if we can align these two projects in this. I had a quick check the branches from TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/. There are three branches in TF-A: - "integration" branch, should be used for new features. - "master" branch, which is behind of "integration" branch. But I am nor sure what is the strategy to update it. - "topics/epic_beta0_spmd", I thinks it should like a feature branch for big feature. @Soby Mathew Could you help to share more information about it? Thanks very much. Hi David W, Thanks for your comments. For your first comment, I will say yes. Sorry to give the CI problem as a reason. For your second comment, I think we can use " git merge <commit-id>" to merge up to a special commit of dev to the master branch. In this, we do not need to freeze the patch merging. Maybe other methods to do it. Sorry, I am not a git expert, please correct me if it is wrong. I agree with you that we need to think clearly about it. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Wednesday, December 11, 2019 3:58 PM To: David Wang (Arm Technology China) <David.Wang(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Hotfix for GNUARM linker script

by David Hu (Arm Technology China)

Hi all, I uploaded a hotfix to fix a issue in GNUARM linker script. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2767 The XXX_ATTR_FN label is named as XXX_LD_ATTR_FN for Application RoT Secure Partitions in GNUARM linker script. Thus GNUARM cannot get the dedicated section address to place the XXX_ATTR_FN section defined in the source code. It may cause linking error and crash during running. Please help review the patch. Any comment is welcome and will speed up the fix. Thank you. Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Gyorgy Szing

Hi, Please sync up with the TF-A team on branching strategy. It would be preferred to keep the two projects aligned if possible. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang (Arm Technology China) via TF-M Sent: 11 December 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by David Wang (Arm Technology China)

Hi Edison, It sounds reasonable to evolve the branch management in TF-M because we get more and more contributions in the community. Thanks for raising that. A few comments: >> * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. This reason of creating dev branch seems like a workaround as CI is not stable. >> * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. If we don’t have the feature branches you proposed, then the problem seems to be the same. It's because dev branch is acting as the master branch and the release(master) branch get "git fast-forward" to a point of dev branch when doing the release. Then we still can't stop merging the unnecessary patches in the release unless we do manual rebase which is not what we wanted. For feature branches, I think it's a good idea but we need to make a process/policy about how/when to create the branches, who maintain the branches and the timing of merging this feature. This could align with the roadmap and release plan, e.g. next release will include a few features/bugfixes which are in corresponding branches. Just share my thoughts. Regards, David Wang Arm Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 2:16 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Create another branch for feature development Hi Kevin, Yes, you are right. The main point does not break a stable branch, it could be the "master" branch or "release" branch. Your suggest is good for it will not conflict with our current patches(upstream to the master branch). But the users may be more like to fetch code from the master branch for a stable version. We can discuss more about it. For this, I think we should discuss if it is necessary to create another branch for release or the stable version firstly. And for "are we already using feature branches such as feature-twincpu?": Yes, you are right again. But current, only several branches are created for huge features. What I mean it that we should not to merge patch to "master" or "release" branch directly. Or we just merge little change patches to master branch. For others, we can create a dedicated feature branch. For example, PSA FF alignment or even a bug fix. Thanks, Edison -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: Wednesday, December 11, 2019 1:43 PM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Create another branch for feature development Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Create another branch for feature development

by Kevin Peng (Arm Technology China)

Hi Edison, In your proposal, the new "develop" branch seems to be the current "master" branch and the "master" branch becomes kind of release branch if I'm understand correctly. So why not create a "release" branch instead. And are we already using feature branches such as feature-twincpu? Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Wednesday, December 11, 2019 11:24 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Create another branch for feature development Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Create another branch for feature development

by Edison Ai (Arm Technology China)

Hi all, I have a proposal to create a "develop"(or something like this) branch in TF-M for our feature development. The reasons for this are: * Reduce the risk to broke the master branch directly especial when the CI cannot work rightly. * We can use the "master" branch only for release, and in this, we do not need to freeze the patch merging when preparing the release. More addition, we can create more branches for big features development, such as "develop/feature_a" or "develop/feature_b". All these new features branch need to be merged to the "develop" branch first and then release to the "master" branch. This is different from the current patch upstream mode, and it needs to spend more time maintaining those branches. But I think it is more convenient for us to develop different features. We do not need to spend more time to fix the conflicts and to do rebase when other patches merge to master branch during patch reviewing. Welcome to comment on this. Thanks, Edison

5 years, 5 months

1
0
0 0

Secure Interrupt handling - RE: TF-M technical Forum slides and recording

by Ken Liu (Arm Technology China)

Thank Bill for updating this. I want to use this thread to follow up on the topic 'secure interrupt' given in the 1st tech forum. That is a prologue of the scheduler and interrupt designs. And I do see there are some use cases that I did not focus on, so I want to collect more user scenarios first, and then try to enhance the drafting design (will be published after I updated it base on your inputs). About the secure interrupt usage: - A secure interrupt would be introduced by a secure service call in general; is there any scenarios that there would be an interval secure interrupt since secure service want to do something? For example, a secure timer triggers to let secure service has the chance to do things in the background (not for an ongoing secure call from NSPE) after a period of time? And the question about the system Alan mentioned, just want to confirm if it is a pure thread mode scheduling system? How does the system handle interrupts? Thanks. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Bill Fletcher via TF-M Sent: Monday, December 9, 2019 7:57 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M technical Forum slides and recording Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

5 years, 5 months

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 5 months

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 5 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Jamie Fox

Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie From: Thomas Törnblom <thomas.tornblom(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis <Minos.Galanakis(a)arm.com><mailto:Minos.Galanakis@arm.com>; 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] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:* tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *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<mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com><mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com><http://www.iar.com> <http://www.iar.com><http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems><http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- 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<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 5 months

2
3
0 0

X.509 Certificate Chain Support in TF-M

by Kevin Townsend

Hi, As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing). The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device. At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval. - Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md - Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md - And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr… - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr… Specifically, they key missing aspects to enable the use of standard X.509 certificates are: - Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c… We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved. Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M. Best regards, Kevin Townsend

5 years, 5 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, November 22, 2019 2:15 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

TF-M Technical Forum call - 5th December

by Bill Fletcher

Hi all, As mentioned in the TF-M workshop in Lyon last month, we propose to kick off the TF-M Technical Forum meeting, starting on the 5th December. This is an open forum for anyone to participate and it is not restricted to TF members. It will operate under the guidance of the TF TSC. - Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings. - Initially we propose a bi-weekly call and then we'll change cadence depending on interest For more details of the call click on the Google Calendar image at https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 5 months

1
0
0 0

TF-M RC3 release

by Tamas Ban

Hi, A new tag TF-Mv1.0-RC3 was created last Friday. The main change since RC2 is that it provides support for integrated Cryptocell-312 cryptographic hardware accelerator on MuscaB1e platform. This enables TF-M to make use of Cryptocell-312 (CC-312) for crypto acceleration during Secure boot and runtime. TF-M is also can use the provisioned HUK (Hardware Unique Key), Attestation key and RoTPK (Root of Trust Public Key) in Cryptocell's OTP memory. Tamas

5 years, 5 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by Minos Galanakis

Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 November 2019 14:49 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Regression test issues with IAR port

by Thomas Törnblom

In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

Re: [TF-M] PSA Certification without PS?

by Shebu Varghese Kuriakose

Hi Andrej/Kevin, Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile* It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met. PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage, maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform. @Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this >>> 5.3 F.SECURE_STORAGE The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to the platform. Only the TOE can retrieve and modify assets from this secure storage. This security function mitigates T.STORAGE by preventing direct and unprotected access to assets. >>> Regards, Shebu * https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le… ** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im… -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, November 28, 2019 7:50 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Certification without PS? Hi Kevin, So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right? Thank you for your clarification, Andrej Butok -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> Sent: Thursday, November 28, 2019 5:14 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>; 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] PSA Certification without PS? A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 5 months

3
3
0 0

Re: [TF-M] PSA Certification without PS?

by Kevin Peng (Arm Technology China)

A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, all, Right, let's see the binary size of a prototype. Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 22 November 2019 10:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The svcall switch-case vs function table Hi Anton, Thanks for the reminder. About code size, two points: - We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func(); - The compiler uses 'TBB' instruction, which is a function table already. So I think it should be okay; we can verify the code size after the prototype is available. BR /Ken -----Original Message----- From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Thursday, November 21, 2019 8:09 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: The svcall switch-case vs function table Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

PSA Certification without PS?

by Andrej Butok

Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Anton Komlev

Hello, I do also support the move to loose the requirement of 80 columns. The real need is outdated and supported as a legacy style, making more trouble than help. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Laurence Lundblade via TF-M Sent: 26 November 2019 21:12 To: Tamas Ban <Tamas.Ban(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline For line length I’m following these rules for t_cose <https://github.com/laurencelundblade/t_cose> - All comments blocks are 80 columns or less - 2% of code lines can be over 80 columns (1% is too few) - No lines over 120 columns I am much happier and think the code is much better by allowing 2% of code lines over 80 columns. I don’t have to make variable names short and obscure, break up if statements in unnatural places, break up for(;;) statements unnaturally and such. LL > On Nov 18, 2019, at 8:31 AM, Tamas Ban <Tamas.Ban(a)arm.com> wrote: > > Hi, > > I would like to open a conversation about TF-M coding guideline <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: > Change the rule of the 80 character column width: > Max 80 characters length. > Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: > Degrades code understandability: short, obscured variable names; > awkward line breaks Maximum 1% of the lines can exceed 80 charter length. > Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: > o Order function parameters so that input params are before output params. > o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…> > > I’m interested in your opinions! Other rules also can be revisited! > > Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Gyorgy Szing

Hi, Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer. Some of the issues which came to my mind: 1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module. 2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms. 3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module. 4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need. 5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be. Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 26 November 2019 19:23 To: Kumar Gala <kumar.gala(a)linaro.org> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies? Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things > you mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli > ght=external > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible > > (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked > out only once it was considered acceptable nuisance, until you do a > pull and version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to > > handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > >> Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting > >> TF-M > working with QEMU. Part of that work is simplifying the setup and > build process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, > >> and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it > >> seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG > bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0 > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Coding guideline

by Tamas Ban

Hi, I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: * Change the rule of the 80 character column width: * Max 80 characters length. * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: * Degrades code understandability: short, obscured variable names; awkward line breaks * Maximum 1% of the lines can exceed 80 charter length. * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: o Order function parameters so that input params are before output params. o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… I'm interested in your opinions! Other rules also can be revisited! Tamas

5 years, 5 months

2
1
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kevin Townsend

Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things you > mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e… > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked out > only once it was considered acceptable nuisance, until you do a pull and > version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting TF-M > working with QEMU. Part of that work is simplifying the setup and build > process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 5 months

1
0
0 0

Design proposal for enabling byte-aligned flash devices.

by Minos Galanakis

Hi all, I have recently submitted the following design proposal, currently under review, which is aimed at enabling byte-aligned flash devices on TF-M https://review.trustedfirmware.org/c/trusted-firmware-m/+/2392 Any feedback, suggestions would be greatly appreciated. Regards, Minos Galanakis

5 years, 5 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Qixiang, It is a very reasonable suggestion. I will write it down as a further improvement. Thanks a lot. Best regards, Hu Ziji -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Including board-specific libraries in TF-M

by Tamas Ban

Hi Kevin, Currently there is no established pattern how to link a library to secure code on platform level. Currently only services and crypto libraries are built as libraries but not platform code. I think the suggested solution (put a `target_link_libraries` entry in that platform/ext/*.cmake file) is feasible, because the platform level cmake files are included by the secure_fw/CMakeList.txt (through CommonConfig.cmake) and in this way the library will be linked to secure code. We have similar solution in case of CC312 library integration: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2526/6/platform… Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 25 November 2019 16:47 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Including board-specific libraries in TF-M Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Qixiang Xu (Arm Technology China)

Correct the mail list address to send it again. -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Edison Ai (Arm Technology China)

Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Including board-specific libraries in TF-M

by Kevin Townsend

Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin

5 years, 5 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Thanks for your inputs. The original intention of the script was to not to modify the origin of the information i.e rst file as Minos quoted and also to avoid duplication of information. Considering all the new information, I think we should try to separate build and post-build dependencies (ex: srec_cat). This separation will allow us to handle all the build dependencies using "cmake" and then we can explore the possible option on how to handle post-build dependencies. @Minos, I believe all sw dependencies defined in https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… are already validated in cmake. Adding other library dependencies into it will make it complete. This way we don’t need mention library dependency in document anymore and still achieve single source of information. @George, I think first 3 question can be answered if we decide to go ahead with handling build dependencies with cmake. Thanks, Dev On 21/10/2019, 15:56, "TF-M on behalf of Gyorgy Szing via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
5
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Adrian Shaw

Page 43 of the PSA Firmware Framework states the following: 1. Even when using these techniques, the latency involved in scheduling a Secure Partition to handle interrupts might not be acceptable for certain types of peripheral. The SPM can implement its own independent device driver model, which provides improved response latency, however, this comes at the cost of portability and security. The SPM’s independent device driver model is not within the scope of this specification. So you are allowed (if you want to implement it in an SP). Best, Adrian On 19 Nov 2019, at 08:07, Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Alan, Thanks for your information. So I think there are 2 discussion here: 1. You had met unexpected behavior when a secure interrupt is configured with a lower priority than pendsv. As I understand, if you just move the pendsv in a higher priority, it should be ok. Just as I say in former mail that the pendsv handler will be processed every time, but it still can works. In this case, the 'd' point you list should not extend to SP. 2. You say that "the SP while it is processing the ISR". Do you mean you want to add a SP ISR? Right? please correct me if it is not. If so the current discussion should be if it is allowed to process ISR in SP: - If allow, "A NSPE interrupt is not allowed to preempt SPE ISR" could be understood as a NSPE interrupt is not allowed to preempt SP ISR. So I think this why you assume the SPE needs to be restored to the IDLE state. - If no. you assume will not reasonable. I think the answer should be NO. PSA FF gives us several APIs to process the interrupt: psa_wait, psa_get, psa_eoi based on the message in the IPC model. In this mechanism, ISR needs to send a signal to SP and let SP process data after scheduling. It is cleaner and security. Thanks, Edison -----Original Message----- From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Sent: Friday, November 15, 2019 4:48 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com<mailto:Edison.Ai@arm.com>> Cc: 'tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: RE: [EXTERNAL] RE: secure interrupt handlng in IPC mode I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM 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] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 5 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 5 months

1
0
0 0

Add hooks for build artifacts custom post-processing

by Andrei Narkevitch

Hi All, I'd like to propose a small change that allows to implement custom build artifacts post processing. In our case, we need to convert tfm_s and tfm_ns binaries into a different file format and implement our custom signing. I expect that other partners eventually may have the same need for build customization. With this, user has an option to implement compiler_custom_post_build command in platform/ext/<platform>.cmake file, and put there all additional custom operations. If command is not implemented, it will be simply ignored. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2588 thanks Andrei This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 5 months

1
0
0 0

Fix for broken AN539 build

by Jamie Fox

Hi all, The build is currently broken for AN539 due to a missing include, so I pushed a quick patch to fix it: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2607 Would appreciate it if anyone with a couple of minutes could review it so that we can merge it quickly. Many thanks, Jamie

5 years, 5 months

1
0
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 5 months

2
1
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by Kevin Peng (Arm Technology China)

Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Abhishek Pandit

Hi Reinhard, We had a discussion in the TSC last week about coding standard. The general consensus was that there multiple possible standards that we can aim for but we need to decide our goal in order to decide the coding standard for the project. I believe Mark G is planning to look at the work ongoing in Zephyr project and provide some details to help us take the discussion forward for TF.org. The input below is helpful, we should take this into the unified effort for coding standard and tooling to enforce it. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 22 November 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Reinhard Keil

Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard 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.

5 years, 5 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
2
0 0

Re: [TF-M] Call for review on header include update

by Abhishek Pandit

Hi Kevin, Yes my email was meant to be on the mailing list. Added back on. Thanks Abhishek -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: 21 November 2019 09:13 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Subject: RE: Call for review on header include update Hi Abhishek, [I guess you are trying to reply to mailing list as well?] I think it's mostly about coding style. Most of the headers are included without any relative path in TF-M. So it's wired that lots of headers are included by a relative path, and relative to the project root make it even more unreasonable. The reason I didn't explain it in detail is that I didn't find any documents about this code style. Of course I had discussions with some team members and they are feeling the same. So I'd like to hear more feedbacks first. Best Regards, Kevin -----Original Message----- From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Thursday, November 21, 2019 4:54 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for review on header include update Hi Kevin, Is there something that explains why this is required? Thanks Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: 21 November 2019 08:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for review on header include update Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Gerrit dashboard for TF-M

by Soby Mathew

Hi, I have created a dashboard for the TF-M project on tf.org to better visualize outstanding patches and the state of patch review : https://review.trustedfirmware.org/#/projects/trusted-firmware-m,dashboards… (old Gerrit UI) https://review.trustedfirmware.org/p/trusted-firmware-m/+/dashboard/site:ma… (new UI) Best Regards Soby Mathew

5 years, 5 months

1
0
0 0

Call for review on header include update

by Kevin Peng (Arm Technology China)

Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin

5 years, 5 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Andrej Butok

Hi David, Let's go further. The main goal of the proposal should be to have the all TFM portable code in one place as much as possible - so the top folder is named as "port". New proposed structure: port |-- platform | | | |-- Partner ABC | | |-- common | | |-- target_abc_1 | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- common | | |-- target_xyz_1 | | |-- target_xyz_2 | |-- ... | -- arch | -- include Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 4:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 5 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Ken Liu (Arm Technology China)

Hi David, The concept itself looks ok for me. So that the scope of vendor would be much clearer. And I think some structure change out of platform folder needs to happen to cooperate with this change, hope to see the detailed analysis result of the changes to be made. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 11:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

[RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Ken Liu (Arm Technology China)

Hi Tamas, The guidelines look good. I would suggest distinguishing these rules between `original tfm created sources` and `3rd party` sources because tfm is now involving some 3rd party projects and we should keep their original taste as much as we could. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: Tuesday, November 19, 2019 11:22 PM To: Kevin Townsend <kevin.townsend(a)linaro.org> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project > added to make enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.c > fg > > The advantage here is that most text editors can be configured to > automatically apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: >> >> * Change the rule of the 80 character column width: >> * Max 80 characters length. >> * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: >> * Degrades code understandability: short, obscured variable names; awkward line breaks >> * Maximum 1% of the lines can exceed 80 charter length. >> * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: >> >> o Order function parameters so that input params are before output params. >> >> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… >> >> I'm interested in your opinions! Other rules also can be revisited! >> >> Tamas >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

CC312 (crypto HW accelerator) integration on Musca-B1

by Tamas Ban

Hi, Musca-B1 board is the target of PSA Level 2 certification. As part of this process we integrated the CC312 crypto HW accelerator with TF-M. The following major changes was done: * Replacement of mbedTLS library to mbed-crypto in MCUBoot. * Integration of CryptoCell-runtime-library to TF-M build system. * Default behaviour of Musca-B1 is unchanged, it use SW only crypto and relying only on mbed-crypto. HW accelerated crypto can be turned on with CMake command line switch: -DCRYPTO_HW_ACCELERATOR=ON * When HW crypto acceleration is enabled then CryptoCell-runtime-library and CC312 HW perform the crypto operations instead of mbed-crypto (mbedTLS). The library provides an mbedTLS compliant API, therefore it requires minimal modification in the code base. * Creating a crypto key provisioning tool to program the TF-M related crypto keys to OTP memory (HUK, ROTPK, attest priv. key). Here we took a sort-cut and currently linked this tool to MCUBoot on demand. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING * Porting of platform layer in Musca-B1 folder to rely on CC312 and OTP memory. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ENABLED * Extends initial attestation API to provide a public API to retrieve the public part of the attestation key. The top of the patch-set: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2539/ We would like to review and merge the changes by 27th of November! Reviewers are welcome! Tamas Ban

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kumar Gala

I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project added to make > enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg > > The advantage here is that most text editors can be configured to automatically > apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make > any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: >> >> * Change the rule of the 80 character column width: >> * Max 80 characters length. >> * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: >> * Degrades code understandability: short, obscured variable names; awkward line breaks >> * Maximum 1% of the lines can exceed 80 charter length. >> * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: >> >> o Order function parameters so that input params are before output params. >> >> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… >> >> I'm interested in your opinions! Other rules also can be revisited! >> >> Tamas >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kevin Townsend

Hi Tamas, Just to add to the conversation, something that the Zephyr project added to make enforcing the coding guidelines easier was a config file for uncrustify. https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify The Zephyr config file itself can be seen here: https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg The advantage here is that most text editors can be configured to automatically apply these rules and avoid common white space or other issues. I've generally found this very useful generating PRs and just ensuring I didn't make any obvious errors when I commit files or changes. Best regards, Kevin On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: > > * Change the rule of the 80 character column width: > * Max 80 characters length. > * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: > * Degrades code understandability: short, obscured variable names; awkward line breaks > * Maximum 1% of the lines can exceed 80 charter length. > * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: > > o Order function parameters so that input params are before output params. > > o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… > > I'm interested in your opinions! Other rules also can be revisited! > > Tamas > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

1
0
0 0

T398/T413, uploaded

by Thomas Törnblom

I have just uploaded the first of a set of changes to allow building TF-M with the IAR toolchain. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 Please review. Thanks, Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 5 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by DeMars, Alan

I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 5 months

2
1
0 0

Re: [TF-M] Commonly accepted default documentation layout

by Christopher Brand

I think you're right that we need some rules like this, and the list below looks reasonable to me. The list should probably be a document in its own right... Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos > Galanakis via TF-M > Sent: Thursday, November 14, 2019 3:14 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Commonly accepted default documentation layout > > Hi > > With our documentation growing, and more people contributing to it, it is > quite essential to start a discussion on some basic commonly accepted rules > about the format of choice. > > Restructured text allows you to achieve similar looking results using multiple > approaches, but this makes it harder for tools like Sphinx to render properly, > since the rendering template can be applied on per project basis, not on a > per file basis. > I took the liberty of investigating the existing documentation, and mostly > looking for top level headers which can be done by using either > > > > #################### > > This is a top-level header > > #################### > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > # Reference docs: > # user_guides/tfm_secure_boot.rst > # user_guides/tfm_user_guide.rst > > > > > > or > > > ==================== > This is a top level header > ==================== > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > > > > Since we are looking for the path of least resistance, I would like to propose > that we follow the format the majority of document uses.This is the format > used in > `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted- > firmware-m.git/plain/docs/user_guides/tfm_user_guide.rst>` . > > When writing a document and coming across a requirement that has not > been defined yet, we should be aiming for compliance with official Python > guidelines<https://devguide.python.org/documenting/#style-guide> which > is the most commonly used notation. > > The following rules should be considered: > > > 1. H1 document title headers should be expressed by # with over-line (rows > on top and bottom) of the text > 2. Only ONE H1 header should allowed per document, ideally placed on top > of the page. > 3. H2 headers should be expressed by * with over-line > 4. H2 header's text should be UNIQUE in per document basis > 5. H3 headers should be expressed by a row of '=' > 6. H4 headers should be expressed by a row of '-' > 7. H3 and H4 headers have no limitation about naming. They can have > similar names on the same document, if they have different parents. > 8. H5 headers should be expressed by a row of '^' > 9. H5 headers will be rendered in document body but not in menus on the > navigation bar. > 10. Do not go deeper than 5 level of heading > 11. When writing guide, which are expected to be able to be readable by > command line tools, it would be best practice to add long complicated tables, > and UML diagrams in the bottom of the page and using internal > references(auto-label). See the current version of the > `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/tru > sted-firmware-m.git/plain/docs/user_guides/tfm_sw_requirement.rst>` > and the proposed patch<https://review.trustedfirmware.org/c/trusted- > firmware-m/+/2456> > > Please let me know if you have any questions/objection or proposals or new > rules you would like to be considered. > > > Thanks, > Minos > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

New platform in TF-M: Musca-S1

by Mate Toth-Pal

Hi All, TF-M support for a new platform Musca-S1 is on review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2452/ We are planning to merge the patch this week. Comments are welcome on the review. Regards, Mate

5 years, 6 months

1
0
0 0

Commonly accepted default documentation layout

by Minos Galanakis

Hi With our documentation growing, and more people contributing to it, it is quite essential to start a discussion on some basic commonly accepted rules about the format of choice. Restructured text allows you to achieve similar looking results using multiple approaches, but this makes it harder for tools like Sphinx to render properly, since the rendering template can be applied on per project basis, not on a per file basis. I took the liberty of investigating the existing documentation, and mostly looking for top level headers which can be done by using either #################### This is a top-level header #################### # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst # Reference docs: # user_guides/tfm_secure_boot.rst # user_guides/tfm_user_guide.rst or ==================== This is a top level header ==================== # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst Since we are looking for the path of least resistance, I would like to propose that we follow the format the majority of document uses.This is the format used in `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` . When writing a document and coming across a requirement that has not been defined yet, we should be aiming for compliance with official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most commonly used notation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, if they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not go deeper than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). See the current version of the `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` and the proposed patch<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2456> Please let me know if you have any questions/objection or proposals or new rules you would like to be considered. Thanks, Minos

5 years, 6 months

1
0
0 0

The svcall switch-case vs function table

by Ken Liu (Arm Technology China)

Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken

5 years, 6 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Edison Ai (Arm Technology China)

Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] secure interrupt handlng in IPC mode

by Mate Toth-Pal

Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan 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.

5 years, 6 months

3
2
0 0

Moving design documents from wiki into source folder with rst format

by Ken Liu (Arm Technology China)

Hi, There are some design documents created earlier is put at wiki. Since they are useful and going to be updated later, we need to move them into source folder with rst format. I have created an issue link for this: https://developer.trustedfirmware.org/T579 The list is here (from link: https://developer.trustedfirmware.org/w/tf_m/): Code Generation With Jinja2 (ongoing) Cooperative Scheduling Rules (ongoing) Inter-Processes Communication Non-secure Client Management (ongoing) Non-Secure Interrupt Handling (ongoing) Secure Partition Interrupt Handling (ongoing) Secure Storage Service Service IPC compatibility - Attestation Service IPC compatibility - SST Trusted Boot Trusted Firmware-m Isolation Level 2 Twin-cpu Uniform Secure Service Signature (ongoing) Some are picked up, the rest are welcome for picking up or comment! Please check the T579 for progress and provide comments in your interested topic - if you found there are some place needs to be updated in these 'old' docs, it is a good chance to update them during the moving. Thanks. /Ken

5 years, 6 months

1
0
0 0

Re: [TF-M] out of tree build

by Kevin Peng (Arm Technology China)

Hi Alan, I'm following on this and will get you updated on any progress. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Thursday, November 7, 2019 12:42 PM To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] out of tree build Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
1
0 0

Last call (for review) before merging linker script changes

by David Hu (Arm Technology China)

Hi all, I'm going to merge the following changes to common linker scripts to support dual-cpu platforms by the end of this week. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-linker-script%2… Those changes mainly focus on making it easier and more comfortable to configure Armv6-M/Armv7-M MPU on a dual-cpu platform. As the changes touch the common linker scripts, I'm sorry if it affects your tasks in hand. Please let me know if the merging concerns you or breaks any urgent task. Thank you. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

Re: [TF-M] extending common linker command file template

by Mate Toth-Pal

Hi Alan, Currently the only way to have custom content in the platform linker config files is to create a platform specific template in the platform directory, and refer to that in the platform CMake file instead of the common one. Although this might not be the best solution, as keeping the platform specific files up to date with the common linker config files can be an extra work. Did you have any specific solution in mind that could handle this situation? Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 14:17 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] extending common linker command file template We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] irqs "source" field

by Ken Liu (Arm Technology China)

Hi Alan, I think the "source" combines the usage of "number" and "name" since a tooling is needed eventually and tool can decide the assigned value is a number or name. Something like: /* Init Secure Partition - here is the pseudo code and does not exist in real sources */ p_irq_ctx = get_interrupt_ctx_by_source (p_manifest->source); /* Tool has converted the number or name into specified source index type */ init_interrupt(p_irq_ctx, THIS_SP); /* SP-IRQ binding is needed */ The 'source' here is just a keyword for tool searching in the platform resource descriptions and be converted into a program recognizable index so that runtime code could know the interrupt context and do something. The irq_number you proposed is direct which is good; but for the name, if we need to do extra operations instead of just know where the handler is, a looking up is still needed based on the irq name provided. That is just my opinion, you can try the email in FF spec for collecting feedbacks: arm.psa-feedback(a)arm.com BR /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Saturday, November 9, 2019 2:38 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] irqs "source" field I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi Reed, Thanks for the input. We name the dual-core/multi-core feature control option flag as `TFM_MULTI_CORE_TOPOLOGY` for a general model. But as Chris said, it would require additional work to design and support more complicated scenarios. Thus for the current particular patches for dual-core platform, I'd like to specify the topic a little as "dualcpu". Best regards, Hu Ziji -----Original Message----- From: Reed Hinkel <Reed.Hinkel(a)arm.com> Sent: Sunday, November 10, 2019 5:45 AM To: Christopher Brand <chris.brand(a)cypress.com>; Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology China) <David.Hu(a)arm.com> Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Makes sense! All the best! Reed On 11/8/19, 11:05 AM, "Christopher Brand" <chris.brand(a)cypress.com> wrote: I think that's actually an argument in favour of "dualcpu" for what we have now, because I suspect there would be significant work needed to support an additional core. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reed > Hinkel via TF-M > Sent: Friday, November 8, 2019 6:53 AM > To: Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology > China) <David.Hu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to > "dualcpu" > > Just food for thought, but in the future some devices may have more than > two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m- > bounces(a)lists.trustedfirmware.org on behalf of tf- > m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the > same in the system. However, the two cores can be in different archs or > even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M > spec > > Could you please let me know if you have any concern about that change? > Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C9dc8588da6e2436e > 754508d76423ef30%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63 > 7087977806556698&sdata=it6Hfh2Vk9A5FUFudmNn206LYO9Wb8lOattG > %2FWsm2%2Bo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

irqs "source" field

by DeMars, Alan

I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan

5 years, 6 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Jay Fallah

Hi Reed; Is there a minimum spec in terms of MCU such as M0 or M0+ or anything else for the RoT functionality MCU? Jay Fallah | Chief Technology Officer | NXM 888-416-6555 | mobile 647-927-9990 | ca.linkedin.com/in/jayfallah CONFIDENTIALITY NOTICE: This email message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > On Nov 8, 2019, at 9:53 AM, Reed Hinkel via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M spec > > Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Reed Hinkel

Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. -Reed On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Andrej Butok

OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 6 months

1
0
0 0

Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Patches to share common code between TF-M ITS and SST services

by Jamie Fox

Hi all, The ITS and SST partitions in TF-M share a common implementation for the backend FS and flash layers, but currently this code is duplicated between the two partitions, increasing overall code size. To fix this, it was previously proposed to keep the common code in only the ITS partition, with SST making service requests to ITS to complete FS and flash operations. The patches to implement this are now available for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2425 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2426 The first patch refactors the FS and flash code in ITS to support multiple contexts, with multiple flash devices. The second refactors SST to make requests to ITS instead of calling the FS code directly, and modifies ITS to handle requests that originate from SST with SST's FS context and flash device. This is a fairly significant change to the architecture of the two services, so feedback would be particularly appreciated. Kind regards, Jamie

5 years, 6 months

1
0
0 0

Re: [TF-M] out of tree build

by Abhishek Pandit

Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Re: [TF-M] Weak symbols

by Grosen, Mark

Before deciding and documenting this, could we review and decide on the overall project's applicable standards? I am guessing that "more strict requirements" might hint at things like MISRAC. I would rather see a general framework for how coding standards are either inherited or defined than one-off choices. There are other questionable coding practices in the current code base that would have trouble with MISRAC. That said, if we will adopt MISRAC, we can also adopt deviations and waivers that allow for (limited) uses of general violations. A well-documented, reviewed and approved deviation is normal practice in most projects trying to adhere to formal quality standards. Mark -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 1, 2019 7:04 AM To: Abhishek Pandit; Christopher Brand; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Weak symbols Hi, In my own words, :) it is one of the steps to be compliant with some coding guidelines with more strict requirements. We are updating the doc to specify the details. Best regards, Hi Ziji ________________________________ From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Friday, November 1, 2019 6:59:32 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Weak symbols Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

out of tree build

by DeMars, Alan

Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan

5 years, 6 months

1
0
0 0

Re: [TF-M] Weak symbols

by Abhishek Pandit

Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

extending common linker command file template

by DeMars, Alan

We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan

5 years, 6 months

1
0
0 0

Re: [TF-M] Weak symbols

by David Hu (Arm Technology China)

Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by DeMars, Alan

After further analysis, I found this to be true: If the secure interrupt has a priority lower than the secure pendsv interrupt, then the associated SP code will run in thread mode at the exception priority level of the secure interrupt. If the priority of the secure interrupt is equal to or greater than the secure pendsv interrupt then associated the SP code will run in thread mode with NO exception priority level. Alan -----Original Message----- From: DeMars, Alan Sent: Tuesday, October 29, 2019 8:54 AM To: 'Mate Toth-Pal' Cc: 'tf-m(a)lists.trustedfirmware.org' Subject: RE: SP thread priority when servicing secure interrupts Mate, I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60. I'll attempt to provide a procedure for reproducing my results. In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Weak symbols

by Christopher Brand

Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Searching the list archives

by Christopher Brand

Is there a "search" interface for this mailing list somewhere? The archive page at https://lists.trustedfirmware.org/pipermail/tf-m/ doesn't seem to provide one (it's not too onerous at the moment to download the 12 gzipped files and search them, but that's going to get worse as time goes by). Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by DeMars, Alan

Mate, I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60. I'll attempt to provide a procedure for reproducing my results. In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by Mate Toth-Pal

Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

SP thread priority when servicing secure interrupts

by DeMars, Alan

It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan

5 years, 6 months

1
0
0 0

Dual core boot design document review

by Christopher Brand

Hi, Back in March, I wrote the dual-core design document at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ It was discussed on the mailing list in a thread that starts at https://lists.trustedfirmware.org/pipermail/tf-m/2019-March/000088.html Since then, TF-M has defined a process for design reviews, and it would be nice to get this design document into the docs/design directory, particularly as the implementation of the design is already in the codebase. Given that there has already been discussion on the mailing list, I've gone ahead and created a review in Gerrit: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2384 I also added all the people who contributed to that thread as reviewers. Please feel free to add yourself as a reviewer. Also, comments on whether this is the right process to follow for design documentation in this transitional state would be useful. Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Mate Toth-Pal

Hi Alan, Andrej is right about PSA certification, for that you don't need to pass the regression test suite. However for submitting a change to the upstream master branch on https://www.trustedfirmware.org/ it is a requirement to pass those tests. The peripherals defined in the tfm_peripherals_def.h files are the peripherals that are mentioned in the 'mmio_regions' node in the partition manifest yaml files. It is a requirement that a macro is defined with this name that is substituted to a pointer type value. For more details see platform\readme.rst, chapter 'platformext/target/tfm_peripherals_def.h'. The type 'tfm_spm_partition_platform_data_t' is defined by the platform implementation, so TF-M core has no knowledge about the content of an object of type 'tfm_spm_partition_platform_data_t', and doesn't use it. The pointer is only considered by it as a token, that is passed to the platform HAL functions. This means that if the platform needs to do nothing related to the peripherals in the HAL functions either because - no isolation is needed to be configured for that peripheral - the peripheral doesn't exist, and the functionality is emulated (1) it is OK to define the value of the macro to be NULL (Just as it is done in platform/ext/target/musca_a/tfm_peripherals_def.h). The TFM_PERIPHERAL_FPGA_IO is used by the core test, to access button state and to blink leds. For the Musca-A platform these functionalities are emulated in the file platform/ext/target/musca_a/plat_test.c TFM_PERIPHERAL_TIMER0 is used by the IRQ tests. The upstreamed platforms all support some kind of timer, so there is a real implementation for all the platforms. (platform/ext/target/musca_a/plat_test.c) If it is not possible to create working implementations for the interfaces in platform/include/tfm_plat_test.h, then it is possible to disable the peripheral access and irq tests, by adding the following lines to the platform cmake file: set(TFM_ENABLE_PERIPH_ACCESS_TEST Off) set(TFM_ENABLE_IRQ_TEST Off) Please note, that even in this case TFM_PERIPHERAL_FPGA_IO and TFM_PERIPHERAL_TIMER0 are still need to be defined (NULL is ok), and the plat_test interface functions also need to have at least an empty implementation. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 24 October 2019 08:39 To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC Regressions reference platform specific resources Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi, The process of contributing to TF-M patch is updated now: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/ We can get an updated version after reviewing. Regards, Summer On 10/23/19, 7:55 PM, "Shebu Varghese Kuriakose via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Align manifest to PSA FF 1.0.0

by Edison Ai (Arm Technology China)

Hi all, I had created a set of patches to align the manifest to PSA FF 1.0.0: https://review.trustedfirmware.org/#/q/topic:manifest_alignment+(status:ope…. The manifest is the basics that are related to almost every module. So please help to review them as far as possible. Thanks, Edison

5 years, 6 months

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Andrej Butok

Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 6 months

1
0
0 0

IPC Regressions reference platform specific resources

by DeMars, Alan

I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan

5 years, 6 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Shebu Varghese Kuriakose

Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi Alan, Thanks for reporting this issue. Yes, the "Create Task" in https://developer.trustedfirmware.org/maniphest is the place you can use. Just create a task, add the tag "Trusted Firmware M" and others you can set as you want or keep them as default. And please add this task link under your commit as comments, please add the test env and result as well if you have. This part needs to be updated, and we will push a patch to fix it ASAP. Regards, Summer On 10/22/19, 2:37 AM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

contributing to the TF-M project

by DeMars, Alan

I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan

5 years, 6 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Gyorgy Szing

Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Minos Galanakis

Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Kumar Gala

This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > 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. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following * Use a reStructuredText grid table to define dependencies * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. Thanks, Dev 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Gyorgy Szing

Hi Kumar, there are some internal discussions on how "build system provisioning" and dependency handling can be enhanced. For now the most convenient might be to use the CI configuration files available here: https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 18 October 2019 15:53 To: David Vincze <David.Vincze(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New tool requirement in TF-M My point was that having them in a file that you an pass to pip install -r would be a useful thing and make setup easier for the user. - k > On Oct 18, 2019, at 2:59 AM, David Vincze <David.Vincze(a)arm.com> wrote: > > Hi Kumar, > > We also have one in TF-M: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/4/doc > s/user_guides/tfm_sw_requirement.rst > > David > > -----Original Message----- > From: Kumar Gala <kumar.gala(a)linaro.org> > Sent: 17 October 2019 15:52 > To: David Vincze <David.Vincze(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] New tool requirement in TF-M > > Might be good to have some kinda of requirements.txt that lists out all python modules needed. > > In zephyr there is: > > https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requi > rements.txt > > You can see the install/setup guide details here: > > https://docs.zephyrproject.org/latest/getting_started/index.html#insta > ll-python-dependencies > > - k > >> On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi All, >> >> We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. >> It adds the cbor 1.0.0 Python package to the list of tools that are >> required to build TF-M. Once it is merged, this package has to be >> installed in the build environment, otherwise the builds will fail. >> The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). >> >> Regards, >> David Vincze >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Kumar Gala

Might be good to have some kinda of requirements.txt that lists out all python modules needed. In zephyr there is: https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requiremen… You can see the install/setup guide details here: https://docs.zephyrproject.org/latest/getting_started/index.html#install-py… - k > On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. > It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package > has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the > following command: pip3 install --user cbor > (or manually after downloading the package from here: https://pypi.org/project/cbor/). > > Regards, > David Vincze > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
2
0 0

New tool requirement in TF-M

by David Vincze

Hi All, We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). Regards, David Vincze

5 years, 7 months

1
0
0 0

Modifying the bootloader - runtime sw interface

by David Vincze

Hi all, I have 3 patches on review (/2149<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2149/>, /2148<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2148/>, /2147<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/>) that will change the interface between MCUBoot and the runtime SW. Currently the bootloader passes the measured boot status data to the attestation service through a shared memory area as individual claims (in TLV format). With these changes the boot status data will be encoded to CBOR format at build time and will be added to the image manifest during the image signing process. The bootloader will share this data the same way as before (as a new type of TLV), however the attestation service will have to handle this data differently as it's already CBOR encoded. This can cause the attestation tests to fail if an older MCUBoot image has been used with a newer build of the secure image or vice versa. To address this issuse / provide backward compatibility the new 'ATTEST_BOOT_INTERFACE' variable will be introduced in the build system (in one of the above patches) to be able to get back the old behavior. For this the 'ATTEST_BOOT_INTERFACE' variable has to be set to "INDIVIDUAL_CLAIMS" in the CMake configuration step: "cmake -G"Unix Makefiles" -DPROJ_CONFIG=../configs/ConfigRegression.cmake -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS ../" The old behavior will be retained for a while, however we have an intention to remove it entirely from the code in the future. Please let me know if you have any questions or concerns. I'd also welcome any feedback on the reviews. Best regards, David Vincze

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by Miklos Balint

Hi Alan, Thanks for the suggestion and the clarifications provided to Ken. During the course of the mail thread, you raised a design principle issue as well as implementation details, and I'll try to address the design principle question later as that is an important topic, but first allow me to touch on one implementation detail for this specific feature: While convenient in GCC, weak symbols are not defined by the C99 standard and their use and syntax is therefore compiler-specific, which is not good from a portability point of view and may cause difficulties with different toolchains. In my opinion a preprocessor-based solution e.g. in the switch-case of the generic SVC handler would be more portable. Could you check the feasibility of that approach? The default expansion could be empty for platforms that do not implement platform-specific SVC handlers, and an arbitrary list of additional case statements for SVC numbers implemented by the platform code for your platform. Please let us know your thoughts, Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 10 October 2019 15:45 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to > support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() >> to support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, >>> flag), SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of >>> user buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' >>> <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> Alan >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

TF-M's Documentation website is live

by Minos Galanakis

Hi all, TF-M's documentation has now launched. The project is using Sphinx to render the documents into HTML which can be accessed via the link bellow: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… The main website has been updated with shortcuts to the new location which can be accessed by navigating at https://www.trustedfirmware.org/ -> Documentation -> Docs > TF-M Thanks, Minos

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >> support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), >>> SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of user >>> buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> Alan >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. Alan > On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. > > I am curious about the requirements you are facing so I am eager to see the changes. > > Thanks. > > /Ken > > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:07 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > Ken, > > If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. > > Alan > >> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >> >> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >> >> While: >> I2c_write(addr, value) { *host_reg_slave_addr = addr; >> *host_reg_slave_data = value; *host_reg_control_go = 1; } >> >> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >> >> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >> >> So the in the handler there would be permission checking: >> >> case SVC_ACCESS_RESOUCE: >> If (spm_check_address_ownership(addr, CURRENT_SP)) >> ret = do_access(addr, data, sz, flags); >> >> And the IIC_WRITE was implemented as: >> I2c_write(addr, value) { *host_reg_slave_addr = addr; >> *host_reg_slave_data = value; *host_reg_control_go = 1; } >> >> Now turned into: >> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), >> SVC_ACCESS(host_reg_slave_data, value, flag), >> SVC_ACCESS(host_reg_control_go, 1, flag)} >> >> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >> >> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 11:14 AM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >> services >> >> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >> >> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >> >> Alan >> >> -----Original Message----- >> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >> Sent: Wednesday, October 9, 2019 7:47 PM >> To: DeMars, Alan >> Cc: nd >> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >> custom services >> >> Hi Alan, >> >> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >> >> The proposed way would be: >> TFM_SVC_ACCESS_RESOURCE >> >> And the parameter would be: >> >> uintptr_t resource_addr /* The address you want to access */ void >> *p_user_buffer /* User-provided buffer */ size_t size /* size of user >> buffer */ uint32_t flags /* Flags, like read/write */ >> >> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 10:27 AM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >> services >> >> Ken, >> >> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >> >> Alan >> >> -----Original Message----- >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >> Of Ken Liu (Arm Technology China) via TF-M >> Sent: Wednesday, October 9, 2019 7:04 PM >> To: tf-m(a)lists.trustedfirmware.org >> Cc: nd >> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >> support custom services >> >> Hi Alan, >> >> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >> >> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >> >> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> DeMars, Alan via TF-M >> Sent: Thursday, October 10, 2019 4:38 AM >> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >> services >> >> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >> >> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >> >> default: >> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >> >> __attribute__((weak)) >> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >> LOG_MSG("Unknown SVC number requested!"); >> return PSA_ERROR_GENERIC_ERROR; } >> >> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >> >> Is this OK? >> >> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >> >> Alan >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

Ken, If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. Alan > On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): > > I2c_write (I2C_ADDR, SLAVE_ADDR, value); > > While: > I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } > > The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. > > The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. > > So the in the handler there would be permission checking: > > case SVC_ACCESS_RESOUCE: > If (spm_check_address_ownership(addr, CURRENT_SP)) > ret = do_access(addr, data, sz, flags); > > And the IIC_WRITE was implemented as: > I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } > > Now turned into: > I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), SVC_ACCESS(host_reg_slave_data, value, flag), SVC_ACCESS(host_reg_control_go, 1, flag)} > > But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. > > If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 11:14 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: RE: augmenting the SVC_Handler_IPC() to support custom services > > I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? > > I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. > > Alan > > -----Original Message----- > From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] > Sent: Wednesday, October 9, 2019 7:47 PM > To: DeMars, Alan > Cc: nd > Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support custom services > > Hi Alan, > > Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? > > The proposed way would be: > TFM_SVC_ACCESS_RESOURCE > > And the parameter would be: > > uintptr_t resource_addr /* The address you want to access */ void *p_user_buffer /* User-provided buffer */ size_t size /* size of user buffer */ uint32_t flags /* Flags, like read/write */ > > Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 10:27 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: RE: augmenting the SVC_Handler_IPC() to support custom services > > Ken, > > There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M > Sent: Wednesday, October 9, 2019 7:04 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > Hi Alan, > > Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. > > From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. > > Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. > We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. > > Thanks. > > /Ken > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, October 10, 2019 4:38 AM > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). > > I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: > > default: > return (custom_ipc_svc_handlers(svc_num, ctx, lr)); > > __attribute__((weak)) > int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { > LOG_MSG("Unknown SVC number requested!"); > return PSA_ERROR_GENERIC_ERROR; > } > > This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. > > Is this OK? > > Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services

by Ken Liu (Arm Technology China)

Hi Alan, The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): I2c_write (I2C_ADDR, SLAVE_ADDR, value); While: I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. So the in the handler there would be permission checking: case SVC_ACCESS_RESOUCE: If (spm_check_address_ownership(addr, CURRENT_SP)) ret = do_access(addr, data, sz, flags); And the IIC_WRITE was implemented as: I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } Now turned into: I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), SVC_ACCESS(host_reg_slave_data, value, flag), SVC_ACCESS(host_reg_control_go, 1, flag)} But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. Thanks. /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, October 10, 2019 11:14 AM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: augmenting the SVC_Handler_IPC() to support custom services I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. Alan -----Original Message----- From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] Sent: Wednesday, October 9, 2019 7:47 PM To: DeMars, Alan Cc: nd Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support custom services Hi Alan, Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? The proposed way would be: TFM_SVC_ACCESS_RESOURCE And the parameter would be: uintptr_t resource_addr /* The address you want to access */ void *p_user_buffer /* User-provided buffer */ size_t size /* size of user buffer */ uint32_t flags /* Flags, like read/write */ Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? Thanks. /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, October 10, 2019 10:27 AM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: augmenting the SVC_Handler_IPC() to support custom services Ken, There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Wednesday, October 9, 2019 7:04 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services Hi Alan, Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Thursday, October 10, 2019 4:38 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom services I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: default: return (custom_ipc_svc_handlers(svc_num, ctx, lr)); __attribute__((weak)) int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { LOG_MSG("Unknown SVC number requested!"); return PSA_ERROR_GENERIC_ERROR; } This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. Is this OK? Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services

by Ken Liu (Arm Technology China)

Hi Alan, Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Thursday, October 10, 2019 4:38 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom services I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: default: return (custom_ipc_svc_handlers(svc_num, ctx, lr)); __attribute__((weak)) int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { LOG_MSG("Unknown SVC number requested!"); return PSA_ERROR_GENERIC_ERROR; } This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. Is this OK? Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: default: return (custom_ipc_svc_handlers(svc_num, ctx, lr)); __attribute__((weak)) int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { LOG_MSG("Unknown SVC number requested!"); return PSA_ERROR_GENERIC_ERROR; } This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. Is this OK? Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. Alan

5 years, 7 months

1
0
0 0

Design proposal: Changing secure service call in library model

by Mate Toth-Pal

Hi All, I'm planning to change the way secure services are called in Library model. The design proposal can be found here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2201/ Please note that the changes proposed by this document does not affect the PSA dev API, and does not affect IPC model. Please share your opinion in gerrit comments Thanks, Mate

5 years, 7 months

1
0
0 0

TF-M Presentations at SanDiego Linaro Connect

by Shebu Varghese Kuriakose

Hi, Here is a link to TF-M presentations from Linaro Connect held in San Diego last month https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_connect_san… Archive of all TF-M presentations can be found in https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/ Regards, Shebu

5 years, 7 months

1
0
0 0

Regression test - SST - MAX_ASSET_SIZE

by Vikas Katariya

Hi, This would test the interface for NS and S with the set, get and remove with maximum `SST_MAX_ASSET_SIZE` and different sizes for all platforms (including feature-twincpu targets in the near future). It uses a common 4K buffer in total to assist with read and write of asset data. We need to make sure we are able to perform this operation flawlessly on all the targets. Patch Review Request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2167 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2168 Thanks & Best Regards, Vikas Katariya 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR

by Jamie Fox

Hi Thomas, One way this can happen is if the QSPI driver is being executed in place from QSPI, so the device is never idle because instructions are being fetched from it. On Musca-A, MCUboot is copied to Code SRAM before being executed to avoid this issue. There is some code in the Armclang/GCC scatter/startup files to support this. Is there something similar implemented for the IAR port? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 27 September 2019 15:40 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Issues with qspi_ip6514e_set_spi_mode with IAR I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Issues with qspi_ip6514e_set_spi_mode with IAR

by Thomas Törnblom

I'm trying to bring up TF-M on the Musca A with IAR Embedded Workbench and I'm having issues in mcuboot where the boot hangs with the following stack: --- qspi_ip6514e_is_idle qspi_ip6514e_set_spi_mode set_spi_mode mt25ql_config_mode ARM_Flash_Initialize main [_call_main + 0xd] --- Apparently the idle bit (31) in the qspi_cfg register (0x4010a000) never gets set so it loops there. I have no programmers manual for the Cadence qspi ip6514e so I'm at a bit of a loss as to what the issue might be. Obviously something is different between the images built with armclang and gcc, which works properly, and the image I've built with IAR. Ideas anyone? /Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 7 months

1
0
0 0

Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot

by Tamas Ban

Hi, In case of no further comment on the proposal I'm planning to merge it by Monday. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 24 September 2019 10:22 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Design proposal for HW crypto key integration in TF-M secure boot Hi, The design proposal about the integration of TF-M secure bootloader (MCUBoot) with HW key(s) are close to finalize: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ If you are interested in the topic and have a comment / suggestion then please share it. Tamas From: Tamas Ban Sent: 03 July 2019 17:50 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Design proposal for HW crypto key integration in TF-M secure boot Hi all, PSA Trusted Boot and Firmware Update specification requires the support of at least one immutable root of trust public key (ROTPK) for firmware verification. It is beneficial to be able to provision these keys during the factory life-cycle of the device independently from any software components. The current key handling solution in TF-M secure boot does not supports this key provisioning process. MCUBoot requires compile time built-in public key(s) for image verification. The following design proposal addressing this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Feel free to add any comments you want on the review! BR, Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Please enable -pedantic-errors for gcc builds

by Ken Liu (Arm Technology China)

Hi Thomas, We tried to enable the "-pedantic-errors" flags and finished some fix. Some of them mentioned in your last mail has been pushed, and updated at: https://developer.trustedfirmware.org/T475 The reason we do not enable it as default is that there some sources files from the external project, which causes inconvenience to enable this. Please help to review these patch to see if it is acceptable for the issue for now, after that we could find a chance to merge it. And we can enable this flag internally and create more patches to fix the tf-m native source in future. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Saturday, August 17, 2019 5:48 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Please enable -pedantic-errors for gcc builds Hi Thomas, This is a very helpful suggestion. Since I am doing some cleanup these days, let me try this option and see how much we need to improve. I have created an task for tracking this: https://developer.trustedfirmware.org/T475 And, do you have an error report could be share? You can attch the log in the task if you do have some. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Friday, August 16, 2019 4:24 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Please enable -pedantic-errors for gcc builds I'm now looking at compilation issues with our standards compliant compiler, and I run into one issue after another that are due to the use of non-standard C allowed by gcc and armclang. Things like zero sized arrays, which are fairly easy to fix by making sure that they have at least one element, but there are other issues that may not be as easy to solve. The latest issue is illegal pointer arithmetic on void * in the IPC code. --- ... [ 20%] Building C object app/secure_fw/CMakeFiles/tfm_s_obj_lib.dir/core/ipc/tfm_svcalls.o msg->invec[invec_idx].base += bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",595 Error[Pe852]: expression must be a pointer to a complete object type msg->invec[invec_idx].base += num_bytes; ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",666 Error[Pe852]: expression must be a pointer to a complete object type tfm_memcpy(msg->outvec[outvec_idx].base + msg->outvec[outvec_idx].len, ^ "C:\Users\thomasto\Projects\tf-m7\trusted-firmware-m\secure_fw\core\ipc\tfm_svcalls.c",750 Error[Pe852]: expression must be a pointer to a complete object type ... --- I suggest enabling "-pedantic-errors" for gcc, and also for clang, if it has a similar setting, to avoid having illegal C code creeping into tf-m. Comments? /Thomas -- *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 <mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> <http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M