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
Hi Jonatan,
The enhancement of this TZ_SAU_Setup() sounds reasonable, and there are more background items to be considerate:
* The SPM need to re-configure the isolation hardware dynamically under isolation level 3 while SPM scheduling, and MPC/PPC is potentially included. So I am not sure what the 'system isolation' mean in your mail, if you want a static initialization for all isolation settings then it will not work for SPM at least for the isolation level 3 design. If it includes the minimal security (and fundamental) setting while system booting and there are other functions to update the isolation setting later, it is do-able.
* How does the parameter pass into this function? Because SPM needs to know the status of the existing isolation setting for some purposes (such as security checking), so there needs to be a way to let SPM know the isolation status.
So if we do the fundamental security setup in SystemInit(), the advantage is the protection is already enabled between SystemInit() exits and SPM_Init() (There are platform init process in this stage). The cons are SPM may not check the isolation status. And if we do isolation in SPM_Init(), the advantage is SPM can know the status and the cons are Platform Init is not restricted (It could access anywhere).
I would suggest not to propose the calling time strictly for this new enhanced API.
I know cypress uses customized protection initialization mechanism so any ideas?
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M
Sent: Tuesday, March 3, 2020 11:09 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TrustZone initialisation procedure
Hi all,
I am trying to align TrustZone initialisation procedure between TF-M and CMSIS.
In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init).
In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()").
The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code.
The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code.
Cheers,
Jonatan Antoni
Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0]
Arm Germany GmbH
Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19
Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309
Geschäftsführer: 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 all,
I am trying to align TrustZone initialisation procedure between TF-M and CMSIS.
In CMSIS the approach from the early v8-M days is to have a "partition.h" file providing "TZ_SAU_Setup()" function. This function is called during low level "SystemInit()" which runs as part of the pre-main (called from ResetHandler and before running C lib init).
In contrast TF-M calls "tfm_spm_hal_init_isolation_hw()" (which is similar to "TZ_SAU_Setup()" plus PPC/MPC configuration) during "tfm_core_init()" (which runs in secure "main()").
The advantage of "TZ_SAU_Setup()" is that this function is available by standard for all TrustZone devices. The shortcoming is it doesn't cover MPC/PPC configuration, yet. Ideally we can enhance CMSIS standard to offer a "TrustZone_Setup()" function (the name is still to be defined) that does all this. That would simplify the TF-M HAL to just one single function call that should be provided by each TrustZone-Device low level init code.
The final question is: When does this function need to be called? Are you aware of any reason why we should not configure the "system isolation" already during low level init (pre-main)? This could simplify TF-M code even more. In TF-M we could simply rely on a properly configured TrustZone isolation before running any TF-M code.
Cheers,
Jonatan Antoni
Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0]
Arm Germany GmbH
Phone: +49 (0)89 262 029 618 | Fax: +49 (0)89 456 040-19
Email: jonatan.antoni(a)arm.com<mailto:jonatan.antoni@arm.com> | Visit: www.keil.com<http://www.keil.com > | Address: Bretonischer Ring 16, 85630 Grasbrunn, Germany
Sitz der Gesellschaft: Grasbrunn | Handelsregister: München (HRB 175362) | USt-IdNr.: DE 187925309
Geschäftsführer: 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 Anton,
> I am not sure if TF-M requires add/remove files
Not physically, but in scope of a project. This is the fact from very beginning.
> With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone.
Yes, but it should be approved and pushed by leaders, otherwise it will not work, and the main leading force of PSA projects is ARM. After that, the approach should be followed by every committer.
Thank you,
Andrej
From: Anton Komlev <Anton.Komlev(a)arm.com>
Sent: Tuesday, March 3, 2020 3:24 PM
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: nd <nd(a)arm.com>
Subject: RE: Call for a feedback on TF-M adaptation experience
Hi Andrej,
Thank you for your feedback!
I am not sure if TF-M requires add/remove files for config change but have to agree that build system requires review and refactoring to be less restrictive and easy for integration.
This is a valuable input for us for improvement planning and task prioritizing.
With this occasion let me remind that TF-M is an open source project where design proposal or code change are welcome from everyone.
Thanks again,
Anton
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: 03 March 2020 13:31
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: Call for a feedback on TF-M adaptation experience
Hi Anton,
The biggest inconvenience for us is the way which TFM is using CMAKE.
The configuration is done on level of CMAKE - adding/deleting/renaming files based on project-level configuration.
So it is difficult to use the original TFM as a component, required for SDKs and CMSIS packs.
For every combination of parameters is needed to create a separate project. As it is not possible, we have to choose one typical configuration.
For example, if a user need to change from Isolation2&IPC to Isolation1&Lib, it is not enough to change configuration parameters, he/she must manually to add/delete source files in the project.
The improvement request:
- platform-independent TFM source-code file set must be fixed for any TFM project.
- optional functionality must be covered by #ifdef - NOT by adding/deleting files.
- allow to change configuration parameters using a user-config file (e.g. as it's done for mbedTLS/Cypto).
All these has no conflict with CMAKE and brings no limits to TFM.
Please, do not ignore it.
Thank you,
Andrej Butok
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: Friday, February 7, 2020 2:13 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: [TF-M] Call for a feedback on TF-M adaptation experience
Dear All,
As I mentioned on yesterday's call, there is a concern on user experience related to TF-M use.
To In order to understand and potentially improve it I am looking for a voice of partners who adopted TF-M project.
Please share your experience and thoughts on parts which are good or might be done better to simplify TF-M integration with your project.
You feedback will be very appreciated in any form - as a response to this mail or as a direct mail to me (anton.komlev(a)arm.com<mailto:anton.komlev@arm.com>) if it's more comfortable for you.
Thank you in advance,
Anton
