Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here.
I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks.
I found the following:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_…
The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything.
Am I missing something?
I'd like to understand more about where TFM is going with the tz_context interface.
Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not.
I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution.
Are there other documents I can read or source implementations I can reference to get more of a handle on this?
Thanks,
Erik Shreve, PSEM
Software Security Engineer & Architect (CMCU Platform Development)
Texas Instruments
Hello,
The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi,
TF-M version information is carried by manifest data, which is appended to the image in a post build step (at image signing):
* Image header: Contains image actual version: 1.0.0
* Image TLV (footer): Can contains a dependency TLV entry which refers to the dependent image by an ID and its minimum version.
Dependency verification:
* At boot time the bootloader checks whether the dependency would be satisfies after a software upgrade. If not then it deny the update.
* https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guide…
At runtime there is no API to get the image version or its capability.
Did I answer your question?
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: 09 March 2020 09:45
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application
Hi,
How does TF-M consider Product Lifecycle Management (PLM)?
Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:
* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration.
* During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.
Questions that I have:
* Is there a way for the Non-Secure application to identify the functionality available in TF-M?
* How is it ensured that new TF-M versions are compatible with previous versions?
Reinhard
Abhishek,
A few days, I posted the reasons why MPC/PPC should not be used for level 3 isolation. Did you had a chance to read that?
MPC/PPC implement system wide isolation. IMHO, reprogramming it for level 3 isolation should be not considered as it creates various problems for the system designer.
You did also ask, how to ensure that security is actually enabled, basically if security has been initalized. The best approach would be to check if the SAU->CTRL is correctly set; if not the system should shut down.
Reinhard
Hi,
How does TF-M consider Product Lifecycle Management (PLM)?
Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:
* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration.
* During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.
Questions that I have:
* Is there a way for the Non-Secure application to identify the functionality available in TF-M?
* How is it ensured that new TF-M versions are compatible with previous versions?
Reinhard
We need to be cognizant of the target usage and user base. The vast majority of usage is v8m in which case the HAL can be simple and targeted for TrustZone. Based on what I have witnessed other than the changes required to support dual/multicore usage. Why not offer a HAL option for TrustZone and one for dual/multicore?
All the best!
Reed
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Abhishek Pandit via TF-M <tf-m(a)lists.trustedfirmware.org>
Reply-To: Abhishek Pandit <Abhishek.Pandit(a)arm.com>
Date: Friday, March 6, 2020 at 4:28 AM
To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TrustZone initialisation procedure
Hi,
I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it’s important to consider what’s platform specific and what’s generic.
In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world.
I don’t disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context.
Thanks,
Abhishek
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 04 March 2020 03:14
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TrustZone initialisation procedure
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<mailto:tf-m-bounces@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<mailto:tf-m@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.
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,
I see this slight differently. The purpose of TF-M HAL is to abstract out specific HW dependencies from the SW framework for creating isolated secure partitions. As you can understand, various systems have differences in what components are utilized for isolation, but TF-M needs to implement a generic mechanism that works across multiple platforms. Therefore it's important to consider what's platform specific and what's generic.
In that sense, SAU and other system components are specific to the underlying HW hence should be part of platform implementation. Of course, it is possible to implement a unified HAL for a family of devices, however I would still expect the hardware abstraction layer in TF-M to remain agnostic of how the HW implements/facilitates isolation of secure world.
I don't disagree with the suggestion about enhancements but they seem platform specific to me so should be discussed in that context.
Thanks,
Abhishek
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 04 March 2020 03:14
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] TrustZone initialisation procedure
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<mailto:tf-m-bounces@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<mailto:tf-m@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 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
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
On 02/03/2020 12:00, Andrej Butok via TF-M wrote:
> Hi,
>
> So, I have submitted the mbedCrypto� issue
> https://github.com/ARMmbed/mbed-crypto/issues/380
>
> Several missed functions were implemented in the latest mbedCrypto.
> Please read the comment.
Hi Andrej,
I will try to answer some of the questions. TF-M currently uses 3.0.1
tag of mbed-crypto and it has all the functions implemented in that version.
We certainly need to be able to migrate to newer versions of mbed-crypto
quicker and more easily. This is one of the things I will be looking
into as part of the improving the crypto service implementation in TF-M.
My current thoughts are that once mbed-crypto implements more of the
other PSA crypto APIs, we could sync up TF-M to expose those APIs.
>
> They also need clarification about the PSA failed test:
>
> 1)�psa_asymmetric_encrypt does not have support for ECC keys� � that's
> true, the specification currently does not define any algorithm for
> psa_asymmetric_encrypt�that uses ECC keys. What's the problem there?
The PSA-ACK test need to fix this. I will highlight this issue to them.
> 2) For the incorrect key derivation error codes, what are the
> problematic inputs?
There is an issue raised with mbed-crypto team discussing this issue
here : https://github.com/ARMmbed/mbed-crypto/issues/175
As I understand, this needs to be fixed by mbed-crypto.
>
> 3) For �psa_generate_key generates incorrect key length for RSA�, what
> are the problematic inputs?
>
> Could you clarify or this is the PSA-Test-Suite task?
The problematic input can be seen here :
https://github.com/ARM-software/psa-arch-tests/blob/master/api-tests/dev_ap…
This is a mismatch between the test and the crypto implementation. PSA
ACK test project had been notified. I will be following up with them.
>
> BTW:
>
> 1) �mbedCrypto does not use the PSA test suite for testing (they have
> own tests).
Yes, that is true.
>
> 2) PSA Test Suite does not inform mbedCrypto about found PSA issues.
There is some communication as seen by the issues referenced above, but
can be better
>
> 3) TFM updates to the latest mbedCrypto have to be more often (ideally
> after each mbedCrypto release).
>
> 4) Better synchronization between the PSA Projects is needed.
>
Yes, certainly. Although syncing to every mbed-crypto release is too
much of an overhead for TF-M and the current plan is to sync up once
mbed-crypto has resolved a sizeable amount of unimplemented APIs. We are
open to contributions in this regard.
Currently, all of them are moving targets, the PSA ACK tests, TF-M,
mbed-crypto and the PSA specification. The mbed-crypto is moving towards
PSA 1.0 whereas the PSA-ACK tests are targeting PSA 1.0 Beta3. This
creates some of the mismatches.
Once the APIs have stabilized, it should be a matter of picking up the
latest mbed-crypto tag and everything should work as expected.
Best Regards
Soby Mathew
> Thanks,
>
> Andrej Butok
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of
> *Andrej Butok via TF-M
> *Sent:* Friday, February 28, 2020 1:20 PM
> *To:* Anton Komlev <Anton.Komlev(a)arm.com>
> *Cc:* tf-m(a)lists.trustedfirmware.org
> *Subject:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
>
> Hi Anton,
>
> OK. So this is the known issue. Is there any plan when it should be
> implemented?
>
> As the test-log is used for a PSA certification, may we disable the
> failed tests?
>
> BTW: As this is known issue, I did not notice it here
> https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen…
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
>
> Thanks,
>
> Andrej
>
> *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 28, 2020 12:14 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:* Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
>
> Hello Andrej,
>
> As you noted, the main reason of test failures is unimplemented PSA
> functions. Those functions are directly dependent on Embed-Crypto
> library where they are missed or API is not adjusted.
>
> Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1
> and will continue so, increasing test suite coverage.
>
> Best regards,
>
> Anton
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org
> <mailto:tf-m-bounces@lists.trustedfirmware.org>> *On Behalf Of *Andrej
> Butok via TF-M
> *Sent:* 28 February 2020 09:46
> *To:* tf-m(a)lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org>
> *Subject:* [TF-M] PSA-Test Suite, 23 Crypto Tests failed
>
> Hello,
>
> After update to the latest TFM and to the latest PSA-Test Suite, 23
> Crypto Tests are failed:
>
> ************ Crypto Suite Report **********
>
> TOTAL TESTS���� : 61
>
> TOTAL PASSED��� : 37
>
> TOTAL SIM ERROR : 0
>
> TOTAL FAILED��� : 23
>
> TOTAL SKIPPED�� : 1
>
> ******************************************
>
> The main reason is that many of PSA Crypto functions are not implemented
> by TFM.
>
> Is there a plan to fix it?
>
> Thanks,
>
> Andrej
>
Hi Reinhard,
Do you mind describing more details about separating single core v8M from dual core v7M?
Do you require more documents or some improvement on code?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: Monday, March 2, 2020 6:10 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Call for a feedback on TF-M adaptation experience
Hi Anton, Hi Kevin,
Thanks for starting this discussion. Let me give you my view on it.
I think the problem can be structured in these parts:
* Give documentation a better overall structure
* Clearly separate single core v8M from dual core v7M
* Describe the overall structure of the files and configuration options of TF-M
* Describe resource requirements of TF-M core
* Describe platform interfaces and provide templates
* Describe how a Service is added to TF-M
* Describe the tools/utilities that are used for TF-M
While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself.
Now let me give more context to each of the above topics.
----
Give documentation a better overall structure
The Trusted Firmware-M documentation starts here:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
While this is already a User's Guide, it contains two more user's guides
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
For an outsider it is unclear where to start.
Clearly separate single core v8M from dual core v7M
This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
Describe the overall structure of the files and configuration options of TF-M
I was looking for something like this:
https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.htmlhttps://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html
Describe resource requirements of TF-M core
Take a look here to understand that request
https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html
Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky.
For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi…
For TF-M this depends on a lot of other parameters.
Describe platform interfaces and provide templates
What I mean by that are the functions itself that are called by TF_M core.
This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc.
https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA…
Describe how a Service is added to TF-M
Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service.
How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it).
Are the any rules for the API interface itself.
You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification.
I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions.
Reinhard
Hi,
So, I have submitted the mbedCrypto issue https://github.com/ARMmbed/mbed-crypto/issues/380
Several missed functions were implemented in the latest mbedCrypto. Please read the comment.
They also need clarification about the PSA failed test:
1)"psa_asymmetric_encrypt does not have support for ECC keys" - that's true, the specification currently does not define any algorithm for psa_asymmetric_encrypt that uses ECC keys. What's the problem there?
2) For the incorrect key derivation error codes, what are the problematic inputs?
3) For "psa_generate_key generates incorrect key length for RSA", what are the problematic inputs?
Could you clarify or this is the PSA-Test-Suite task?
BTW:
1) mbedCrypto does not use the PSA test suite for testing (they have own tests).
2) PSA Test Suite does not inform mbedCrypto about found PSA issues.
3) TFM updates to the latest mbedCrypto have to be more often (ideally after each mbedCrypto release).
4) Better synchronization between the PSA Projects is needed.
Thanks,
Andrej Butok
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Friday, February 28, 2020 1:20 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
Hi Anton,
OK. So this is the known issue. Is there any plan when it should be implemented?
As the test-log is used for a PSA certification, may we disable the failed tests?
BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen…<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>
Thanks,
Andrej
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 28, 2020 12:14 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: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
Hello Andrej,
As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted.
Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage.
Best regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 28 February 2020 09:46
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
Hello,
After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed:
************ Crypto Suite Report **********
TOTAL TESTS : 61
TOTAL PASSED : 37
TOTAL SIM ERROR : 0
TOTAL FAILED : 23
TOTAL SKIPPED : 1
******************************************
The main reason is that many of PSA Crypto functions are not implemented by TFM.
Is there a plan to fix it?
Thanks,
Andrej
Hi Anton, Hi Kevin,
Thanks for starting this discussion. Let me give you my view on it.
I think the problem can be structured in these parts:
* Give documentation a better overall structure
* Clearly separate single core v8M from dual core v7M
* Describe the overall structure of the files and configuration options of TF-M
* Describe resource requirements of TF-M core
* Describe platform interfaces and provide templates
* Describe how a Service is added to TF-M
* Describe the tools/utilities that are used for TF-M
While the debugging aspect raised by Kevin is relevant, it is a generic problem for all v8-M projects, not just for TF-M. I'm supportive to provide tools like pyOCD, but we need proper resourcing for it (maybe a separate project). It should be also noted that the industry works typically with tools like EWARM, MDK, or vendor specific tools like STCube or MCUxpresso. Hence we should not directly add too much tool-specific information to TF-M itself.
Now let me give more context to each of the above topics.
----
Give documentation a better overall structure
The Trusted Firmware-M documentation starts here:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
While this is already a User's Guide, it contains two more user's guides
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
For an outsider it is unclear where to start.
Clearly separate single core v8M from dual core v7M
This seems to be somewhat better now as it seems that below only refers to v8M single core: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
Describe the overall structure of the files and configuration options of TF-M
I was looking for something like this:
https://arm-software.github.io/CMSIS_5/RTOS2/html/pDirectory_Files.htmlhttps://arm-software.github.io/CMSIS_5/RTOS2/html/config_rtx5.html
Describe resource requirements of TF-M core
Take a look here to understand that request
https://arm-software.github.io/CMSIS_5/RTOS2/html/pHardwareRequirements.html
Important is also to document the interrupt behaviour (for both the secure and non-secure side). I know that this is tricky.
For RTX we have this here: https://arm-software.github.io/CMSIS_5/RTOS2/html/cre_rtx_proj.html#cre_Usi…
For TF-M this depends on a lot of other parameters.
Describe platform interfaces and provide templates
What I mean by that are the functions itself that are called by TF_M core.
This is an example of the OS_Tick interface that RTX is using. TF-M core has similar interfaces to setup MPC, PPC, SAU, etc.
https://arm-software.github.io/CMSIS_5/RTOS2/html/group__CMSIS__RTOS__TickA…
Describe how a Service is added to TF-M
Assume I have functions currently used in NS. What would be the process to move this functions into TF-M as a service.
How does the API interface change, what modifications do I need (ideally I would like to have the same API interface after it).
Are the any rules for the API interface itself.
You could also provide an example for that, i.e. functions that read a PIN number from an secure keypad or open a DOOR depending on a verification.
I know making a good product is hard and takes time. CMSIS is not perfect either. Let me know if you have any questions.
Reinhard
Hi Anton,
OK. So this is the known issue. Is there any plan when it should be implemented?
As the test-log is used for a PSA certification, may we disable the failed tests?
BTW: As this is known issue, I did not notice it here https://github.com/ARMmbed/mbed-crypto/issues?page=1&q=is%3Aissue+is%3Aopen…
Thanks,
Andrej
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, February 28, 2020 12:14 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
Hello Andrej,
As you noted, the main reason of test failures is unimplemented PSA functions. Those functions are directly dependent on Embed-Crypto library where they are missed or API is not adjusted.
Recently TF-M was upgraded Embed-Crypto library from v1.0.0 to v3.0.1 and will continue so, increasing test suite coverage.
Best regards,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: 28 February 2020 09:46
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA-Test Suite, 23 Crypto Tests failed
Hello,
After update to the latest TFM and to the latest PSA-Test Suite, 23 Crypto Tests are failed:
************ Crypto Suite Report **********
TOTAL TESTS : 61
TOTAL PASSED : 37
TOTAL SIM ERROR : 0
TOTAL FAILED : 23
TOTAL SKIPPED : 1
******************************************
The main reason is that many of PSA Crypto functions are not implemented by TFM.
Is there a plan to fix it?
Thanks,
Andrej
