Hi Reinhard,
About the CMSIS documentation change, could you share us the difference to be updated?
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: Tuesday, April 28, 2020 10:54 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION
Hi Ken,
Thanks for feedback.
TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_…
The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface.
RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread.
When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version.
Long story short:
* I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice.
* I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution.
In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works.
Reinhard
Hi Thomas,
OK, the problem is caused by that the names of region related symbols that IRA compiler generate are different with those of ARMCLANG. The work around below do can solve the problem.
BTW the work around seems not to be a general one. I think another way to solve the problem is adding a macro like SYMBOL_NAME_BASE(region) which is a wrapper of the REGION_NAME on different compilers.
Regards,
Sherry Zhang
From: Thomas Törnblom <thomas.tornblom(a)iar.com>
Sent: Tuesday, April 28, 2020 6:28 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] REGION_DECLARE macros
Hi Sherry,
Yes, I noticed that this change had been integrated and that this symbol was being used.
I ran into a lot of these during the IAR port and as I said they don't work with the IAR linker.
I work around this in CommonConfig.cmake by this define:
---
embedded_set_target_compile_flags(TARGET ${tgt} LANGUAGE C FLAGS ${COMMON_COMPILE_FLAGS} "-DImage$$= " "-DLoad$$LR$$= " "-D$$ZI$$Base=$$Base" "-D$$ZI$$Limit=$$Limit" "-D$$RO$$Base=$$Base" "-D$$RO$$Limit=$$Limit" "-D$$RW$$Base=$$Base" "-D$$RW$$Limit=$$Limit" "-D_DATA$$RW$$Base=_DATA$$Base" "-D_DATA$$RW$$Limit=_DATA$$Limit" "-D_DATA$$ZI$$Base=_DATA$$Base" "-D_DATA$$ZI$$Limit=_DATA$$Limit" "-D_STACK$$ZI$$Base=_STACK$$Base" "-D_STACK$$ZI$$Limit=_STACK$$Limit"
---
i.e. I replace $$ZI$$Base with $$Base, Image$$ and Load$$LR are removed entirely, and so on.
To make this work I need to split the symbol up into its components, which is done with the REGION macros.
So the symbol "Image$$ARM_LIB_STACK_MSP$$ZI$$Base" turns into "ARM_LIB_STACK_MSP$$Base", which is what we use for IAR. For ARMCLANG and GNUARM the macros generate the original symbol.
Cheers,
Thomas
Den 2020-04-28 kl. 12:03, skrev Sherry Zhang:
Hi Thomas,
The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 .
REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h
So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler?
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: Tuesday, April 28, 2020 4:58 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] REGION_DECLARE macros
I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software.
Trying another type:
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
Den 2020-04-28 kl. 10:51, skrev Thomas T�rnblom via TF-M:
With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains.
Example diff:
---
���� /* Set Main Stack Pointer limit */
-��� extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
-��� __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+��� REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,� $$ZI$$Base);
+��� __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+��������������������������������������� $$ZI$$Base));
---
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>
--
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>
--
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 Ken,
Thanks for feedback.
TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_…
The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface.
RTOS Thread Context Management<https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT…> relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread.
When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version.
Long story short:
* I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice.
* I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution.
In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works.
Reinhard
Hi Reinhard,
Add more from user's perspective:
The non-secure client id can be used to identify different "clients" from non-secure side. The example from tf-m existing secure service is the storage. Different client id can access different storage space. Therefore, the storage is "isolation" among the clients.
The users can create the custom secure service and leverage different client ids (let's say non-secure client id here) to identify different non-secure "callers":
* The meaning of identifying different non-secure callers depends on the user case of the secure service. For example, different storage spaces, different access permissions, etc.
* In RTOS, different non-secure client ids are managed via TZ_APIs (https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu…) if they're enabled.
* The mapping between non-secure applications and the TZ secure contexts (stand for different client ids in tfm) is managed by NS RTOS kernel. When the ns applications get updated, then the mapping should also be maintained by RTOS kernel.
Hope this helps.
Refs:
[1]: TF-M non-secure ID manager http://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides…
[2]: PR to FreeRTOS which uses different non-secure id for storage service: https://github.com/Linaro/amazon-freertos/pull/1
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Tuesday, April 28, 2020 7:00 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION
Hi Reinhard,
My assumption on the user side:
- For application developers, they don't need to care about the identification and just access secure service via API.
- For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management.
Still need the real USER to provide more information in case my assumption covers partial scenarios only.
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Reinhard Keil via TF-M
Sent: Tuesday, April 28, 2020 2:57 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] Questions on TFM_NS_CLIENT_IDENTIFICATION
I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled.
However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime.
Reinhard
Hi Reinhard,
My assumption on the user side:
- For application developers, they don't need to care about the identification and just access secure service via API.
- For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management.
Still need the real USER to provide more information in case my assumption covers partial scenarios only.
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: Tuesday, April 28, 2020 2:57 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION
I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled.
However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime.
Reinhard
Hi Thomas,
The diff below is caused by this patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/3942 .
REGION_NAME is used to pasting the input parameters into a string. So there should be no difference between Image$$ARM_LIB_STACK_MSP$$ZI$$Base and REGION_NAME(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base) basing on the current implementation of REGION_NAME in file platform/include/region.h
So, is there a specific REGION_NAME macro implementation for IAR compiler? Or the automatically generated region related symbols are with different names in IAR compiler?
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Thomas Törnblom via TF-M
Sent: Tuesday, April 28, 2020 4:58 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] REGION_DECLARE macros
I have no idea what causes the crap characters in the diff below, they should be blanks. Looks like a problem with the mailing list software.
Trying another type:
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
Den 2020-04-28 kl. 10:51, skrev Thomas T�rnblom via TF-M:
With the integration of the IAR toolchain support in TF-M it has become important to use the REGION_DECLARE/REGION_NAME macros in platform/region.h instead of using symbols like "Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
The IAR linker can not use these symbols and the macros in combination with the IAR specific cmake rules creates appropriate symbols for all the supported toolchains.
Example diff:
---
���� /* Set Main Stack Pointer limit */
-��� extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
-��� __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+��� REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,� $$ZI$$Base);
+��� __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+��������������������������������������� $$ZI$$Base));
---
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>
--
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>
I have no idea what causes the crap characters in the diff below, they
should be blanks. Looks like a problem with the mailing list software.
Trying another type:
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
Den 2020-04-28 kl. 10:51, skrev Thomas Törnblom via TF-M:
> With the integration of the IAR toolchain support in TF-M it has
> become important to use the REGION_DECLARE/REGION_NAME macros in
> platform/region.h instead of using symbols like
> "Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
>
> The IAR linker can not use these symbols and the macros in combination
> with the IAR specific cmake rules creates appropriate symbols for all
> the supported toolchains.
>
> Example diff:
> ---
> ���� /* Set Main Stack Pointer limit */
> -��� extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
> -��� __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
> +��� REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP,� $$ZI$$Base);
> +��� __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
> +���������������������������������������
> $$ZI$$Base));
> ---
>
> 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>
>
--
*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>
With the integration of the IAR toolchain support in TF-M it has become
important to use the REGION_DECLARE/REGION_NAME macros in
platform/region.h instead of using symbols like
"Image$$ARM_LIB_STACK_MSP$$ZI$$Base".
The IAR linker can not use these symbols and the macros in combination
with the IAR specific cmake rules creates appropriate symbols for all
the supported toolchains.
Example diff:
---
/* Set Main Stack Pointer limit */
- extern uint32_t Image$$ARM_LIB_STACK_MSP$$ZI$$Base;
- __set_MSPLIM((uint32_t)&Image$$ARM_LIB_STACK_MSP$$ZI$$Base);
+ REGION_DECLARE(Image$$, ARM_LIB_STACK_MSP, $$ZI$$Base);
+ __set_MSPLIM((uint32_t)®ION_NAME(Image$$, ARM_LIB_STACK_MSP,
+ $$ZI$$Base));
---
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>
I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled.
However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime.
Reinhard
Hi Reinhard
I think the closer to a high level documentation is this page:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…
To your question regarding the nv counters, they are currently used by MCUBOOT and Protected Storage Service. You may be interested in this patch under review which is will expose them as a service
https://review.trustedfirmware.org/c/trusted-firmware-m/+/3367
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Reinhard Keil via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 27 April 2020 16:07
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Documentation for platform interfaces
Is there somewhere a high-level documentation for the platform interfaces that are here:
https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/includ…
What are the dependencies of the services to the platform files?
For example, when is nv_counters used?
Reinhard
