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