Hi Reinhard, All,

Thanks to your research we have exact measurements before any improvements. Good to know it. Suppose I have heard same order numbers on one of Tech Forums or during Workshop in Lyon. I think such issues shall be addressed via design proposal, review in community ended with code change. Personally I like your suggestions. Let's discuss it on one of Tech Forums.

Best Regards, Anton Komlev

From: Reinhard Keil Reinhard.Keil@arm.com Sent: 04 March 2020 13:56 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com; Anton Komlev Anton.Komlev@arm.com Subject: Entry to TF-M

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