- TF-M - lists.trustedfirmware.org

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

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

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

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

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

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

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

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

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

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

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M