- TF-M - lists.trustedfirmware.org

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

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

5 years, 6 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Sherry Zhang

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)&REGION_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)&REGION_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>

5 years, 6 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

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

5 years, 6 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by David Wang

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

5 years, 6 months

1
0
0 0

Re: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION

by Ken Liu

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

5 years, 6 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by 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)&REGION_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)&REGION_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>

5 years, 6 months

1
0
0 0

Re: [TF-M] REGION_DECLARE macros

by Thomas Törnblom

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)&REGION_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)&REGION_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>

5 years, 6 months

1
0
0 0

REGION_DECLARE macros

by Thomas Törnblom

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)&REGION_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>

5 years, 6 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

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

5 years, 6 months

1
0
0 0

Re: [TF-M] Documentation for platform interfaces

by Minos Galanakis

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

5 years, 6 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - April 30

by Ken Liu

Hi Anton, I would like to give a brief introduction for a mechanism which would improve the coding efficiency and performance for RoT Service API by avoiding 'psa_connect'/'psa_close'. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 23, 2020 3:29 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - April 30 Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Documentation for platform interfaces

by Reinhard Keil

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

5 years, 6 months

1
0
0 0

Re: [TF-M] PSA Crypto failure with addition of persistent keys

by David Hu

Hi Raymond, Sorry for the trouble. Sorry that I cannot find a Crypto test case with index 250. Could you please share more details and error logs of this test case? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: Monday, April 27, 2020 10:26 AM To: tf-m(a)lists.trustedfirmware.org; Jamie Fox <Jamie.Fox(a)arm.com> Subject: [TF-M] PSA Crypto failure with addition of persistent keys Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. 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.

5 years, 6 months

1
0
0 0

PSA Crypto failure with addition of persistent keys

by Raymond Ngun

Hi Jamie, With the addition of persistent key support, we have seen the PSA Crypto test hang at test 250. Although we originally saw this with PSoC64, I was able to reproduce this problem on a Musca-B1. Can you please have a look please? Note that the behavior is not always the same. I have 2x Musca-B1 boards and they both failed the first time I ran the PSA Crypto test suite. However, they both did not freeze on a 2nd run. Possibly a stack issue such that the behavior is dependent on what is in stack. Thank you, Ray This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model

by Ken Liu

Looks no more feedbacks. We will start creating it and call for review when finished. Issue created for collecting comments: https://developer.trustedfirmware.org/T720 Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, April 9, 2020 4:32 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /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: Thursday, April 9, 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] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

5 years, 6 months

1
0
0 0

Request for comments on TF-M Profile Small design updates

by David Hu

Hi all, Hope you are doing well. May I ask for your review on the latest Profile Small design? The design has been updated with following major changes: * The default AES mode is changed to CCM mode from CBC mode, to achieve more secured connection. * More details on the use case of Profile Small Please review the document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Please feel free to comment. Thank you! The patch set is updated as well, following the latest design. Please check it on https://review.trustedfirmware.org/q/topic:%22profile-s-config%22+(status:o…. Compared with previous versions, CCM is supported and some configurations are selected to optimize the Crypto memory footprint. Best regards, Hu Ziji

5 years, 6 months

1
0
0 0

TF-M Technical Forum call - April 30

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, April 30 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Bug fix merged: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3943 -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:26 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Bug being tracked at https://developer.trustedfirmware.org/T716, aiming to get the fix pushed in a few minutes Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 13:06 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Tamas Ban

Thanks Thomas to let us know! Fix will be pushed soon! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: 20 April 2020 14:05 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Build issues with MCUBoot merge Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] Build issues with MCUBoot merge

by Raef Coles

Looks that that should be an ifdef not an if, and it's always worked because the syntax error isn't noticed if the condition is false. Looks to have been 056ed0bd4 that broke it based on a quick git blame. I'll get a defect created and get a patch sorted. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 20 April 2020 12:47 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Build issues with MCUBoot merge I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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> 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.

5 years, 6 months

1
0
0 0

Build issues with MCUBoot merge

by Thomas Törnblom

I just noticed that there has been an MCUBoot patch merged, which appears to cause build issues in loader.c for MUSCA_A, which seems to be the only target requiring RAM_LOADING: --- [ 98%] Building C object bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o C:/Users/thomasto/Projects/tf-m2/trusted-firmware-m/bl2/ext/mcuboot/bootutil/src/loader.c:189:24: error: expected value in expression #if MCUBOOT_RAM_LOADING ^ 1 error generated. make[2]: *** [bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/build.make:341: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/bootutil/src/loader.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1265: bl2/ext/mcuboot/CMakeFiles/mcuboot.dir/all] Error 2 make: *** [Makefile:118: all] Error 2 --- 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>

5 years, 6 months

1
0
0 0

Re: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future?

by Shebu Varghese Kuriakose

Hi Matt, TF-M plans to continue using Mbedcrypto in the crypto service. Mbed Crypto implements the PSA Crypto APIs and is also now part of trustedfirmware.org community project alongside TF-M. However, it is possible with some effort for a platform using TF-M to use another crypto library in the TF-M crypto service. Of course the library will need to support PSA Crypto APIs to be PSA compliant. There is support for ARIA, Camellia in Mbed TLS. There has already been a PR for SM4 support sometime back - https://github.com/ARMmbed/mbedtls/pull/1165. SM2/SM3 algorithm support can be contributed to MbedTLS project (Mbed Crypto is now merged to Mbed TLS project). The maintainers will have to review and integrate the contribution as their bandwidth permits while finding time to review several contributions that the project is receiving. I am adding psa-crypto mailing list which is used for Mbedcrypto/PSA Crypto discussions. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Matt via TF-M Sent: Thursday, April 16, 2020 8:24 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Will TFM crypto service suppot national encryption algorithm in the future? Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 6 months

2
1
0 0

Will TFM crypto service suppot national encryption algorithm in the future?

by Matt

Hi All TFM experts, TFM crypto service is based on mbedcrypto and there is no national encryption algorithm support in current mbedcrypto implementation. The Chinese market has a strong demand for national encryption algorithms, such as SM2/SM3/SM4, will TFM crypto service change to other crypto implementation to support the national encryption algorithm in the future? Thanks, -Matt

5 years, 6 months

1
0
0 0

Re: [TF-M] [TF-A] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi all, Thanks to all who have commented on this proposal so far. I've edited the original document to try and incorporate all feedback gathered so far (through the TSC meeting, this email thread and the TF-A tech call). Please have another look and flag anything I might have missed: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… The major changes are: == Removed concept of self-review == This is proving too controversial, several people do not want to allow self-review. Roles of maintainer and code owner are still cumulative but cannot be both exercised for the same patch. The exact method of dealing with review bottleneck is still to be decided. In addition to the current proposal of increasing the maintainers pool, the most popular alternatives mentioned so far are: - Set a minimum wait time for feedback before a patch can be merged without any further delay. - Mandate distinct reviewers for a patch. == Enhanced the section "Patch contribution Guidelines" == Mentioned that patches should be small, on-topic, with comprehensive commit messages. == Added a note about how to deal with disagreement == If reviewers cannot find a common ground, the proposal is to call out a 3rd-party maintainer. == Removed "out-of-date" platform state == Squashed it into "limited support" to reduce the number of states. == Removed "orphan" state from platform support life cycle == This concept is orthogonal to the level of functionality. Added a note in the "Code Owner" section instead. == Per-project guidelines as a complementary document == Added a list of things that it would typically cover. == Added requirement on fully supported platforms to document the features they support == == Added todo mentioning that the proposal might cover branching strategies in the future == The full diff may be seen here: https://developer.trustedfirmware.org/phriction/diff/73/?l=4&r=5 This proposal is still open for discussion at this stage and further feedback is most welcome! Regards, Sandrine

5 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M