Hi Alan,
It (8.3.5) is one of the cases can be dealt with, and now it is not detail defined yet. Can you describe what your practical purpose for S/NS interactive is so that we could collect feedbacks to check if the rules are applicable?
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: Wednesday, March 4, 2020 10:51 PM
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] SPM_IDLE
Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called.
Alan
I have just pushed a simple one liner for
tools/tfm_parse_manifest_list.py, which keeps the generated #include
file names using unix style paths, even if the files were generated on
windows.
In the past I have manually fixed up the paths on the generated #include
lines in some of the files, but got bored and fixed the script instead.
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3605
I also pushed a major (80 files) fix last night that cleans up most of
the warnings when building with the IAR toolkit, which for now has more
warnings enabled than ARMCLANG and GNUARM. This should make it easier to
enable "pedantic" mode with GNUARM as well.
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3594
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>
Hi,
Today, I measured the call overhead on the function entry to TF-M is significant and will cause side effects for time deterministic MCU applications using the MDK debugger on STM32L5.
Compiler: AC6.14 -oz (optimized for image size)
TFM configuration: TFM_LVL=1, library mode, TFM_NS_CLIENT_IDENTIFICATION = OFF
--- Execution time measurement:
Function call of NS psa_open_key to corresponding secure function:
NS: dispatch -> S: tfm_crypto_open_key 2135 cycles
NS: dispatch -> S: psa_open_key 2536 cycles
NS: psa_open_key -> S: psa_open_key 2825 cycles (this is with RTOS mutex overhead)
tfm_core_sfn_request(const struct tfm_sfn_req_s *desc_ptr)
{
__ASM volatile(
"PUSH {r4-r12, lr} \n"
"SVC %[SVC_REQ] \n" <--- effectively disables interrupts for 1970 Cycles
"MOV r4, #0 \n"
On Musca (~48MHz) the overhead is 45us for a TF-M call.
--- Code Size overhead:
Each TFM function has the following flow:
tfm_ns_interface_dispatch (this is a central function)
#33 result = fn(arg0, arg1, arg2, arg3); -> calls each TF-M function with individual veneer
tfm_core_partition_request (which is again central function)
As function inlining is used, the each veneer requires 180 bytes.
In my system there are 4 ITS and 46 Crypto functions; with the net result of ~10K code for just the veneer entries.
Here are some suggestions:
* Using a central entry point to TF-M could save ~10KB; I suggest a table driven approach (could be generated from "manifest" information).
* In LVL1 isolation, why is it required to switch from NS: thread->S: handler->S: thread mode. Is it not possible to just call NS: thread-> S: thread?
* Disabling NS interrupts for 1970 cycles will be problematic for many time critical applications that are ISR driven; some is caused by parameter checking:
* current sequence: first check, then copied (which requires to disable interrupts); Better: First copy, then check could avoid ISR blocking.
I hope this helps to improve TFM.
Reinhard
Hi Reinhard,
On Wed, 4 Mar 2020 at 15:41, Reinhard Keil via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Is there a forum call tomorrow?
>
Yes there is. At 0700 UTC.
>
>
> Where can I find the dail-in information?
>
Clicking on the Google calendar image on
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ should take
you to the invite.
Regards
Bill
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
--
[image: Linaro] <http://www.linaro.org/>
*Bill Fletcher* | *Field Engineering*
T: +44 7833 498336 <+44+7833+498336>
bill.fletcher(a)linaro.org | Skype: billfletcher2020
TFM_NS_CLIENT_IDENTIFICATION seems to be a feature of the v8M implementation only. Is this correct?
Is this feature explained somewhere?
As it is disabled in the implementation that I'm using, would it be possible to complete the removal of code that implements it?
Thanks
Reinhard
ti
Mention is made to "SPM_IDLE" in the Cooperative Scheduling Rules document:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
I'm struggling to understand section 8.3.5 which references SPM_IDLE but doesn't really define it. Is there more info on this topic? It appears to be a proposed solution for allowing other NS threads to be scheduled while the current NS thread is waiting for an asynchronous event in the secure service it has called.
Alan
Just some minor observation:
There are various variants of memory functions in tfm core
* tfm_memory_utils.h defines a set of identical functions
* tfm_core_utils.c/h has another set - functional equivalent with the C run-time library
Why are these functions duplicated? It would be Ok if they address some additional security concerns (that I currently don't understand). But todays implementation just add complexity.
Reinhard
Hi Ken, Hi Jonatan,
Here is how I see it:
* PPC, MPC control system wide the access rights; DMA and other bus masters cannot bypass
* SAU controls the access rights on the Processing Element
* MPU controls the access rights within a execution domain (secure, non-secure)
The setup for TF-M should be:
* Isolation Level 1: static SAU, PPC, MPC setup
* Isolation Level 2: adds static MPU setup (for privilege, non-privilege separation - could be reflected in PPC, MPC when it is supported by the device)
* Isolation Level 3: dynamic MPU setup (depending on the service executed)
Changing PPC, MPC setup dynamically does not make sense, as in most devices DMA could bypass TF-M.
If this schema is acceptable, TF-M could always assume correct setup of Isolation level 1. A static #define could reflect that.
If you think it should be different, please explain why a different schema would add further security to the overall system.
Reinhard
