- TF-M - lists.trustedfirmware.org

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Thanks, The library model seems to treat the entire SPE as a single resource as it appears to lock and only allow a single entry at a time: /* This is the "Big Lock" on the secure side, to guarantee single entry * to SPE */ extern int32_t tfm_secure_lock; Is this a limitation of the current implementation or is this the envisioned design for the library model? If the latter, is there a technical/security reason why only a single entry is allowed? Or is it that no use-case to allow multiple entry has been discussed. To back up a bit, we have use cases where I would like to see the NSPE RTOS make all the scheduling decisions and further have all the secure peripheral resources be managed individually with respect to blocking threads. The IPC model seems to be built around having a scheduler in the SPM and the library model seems to preclude the ability to manage secure peripherals individually. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, March 13, 2020 7:50 AM To: Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context 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

5 years, 7 months

2
1
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Yes, the two working models are mutually exclusive, and the model is selected compile time, by choosing a corresponding config cmake file. I'm afraid there isn't a comprehensive specification for the Library model, like for IPC model. For examples on calling services in library model, you can have a look in the Secure Service API implementations. Look in interface/src for NS, and in the directory of the services, for example services/initial_attestation/tfm_attestation_secure_api.c for secure examples. The working model specific code parts that are in common files are (across the whole TF-M codebase) guarded by the TFM_PSA_API define: #ifdef TFM_PSA_API /* IPC model implementation */ #else /* TFM_PSA_API */ /* Library model implementation */ #endif /* TFM_PSA_API */ If a source file is IPC model specific it has 'ipc' in its name, or is in a directory called 'ipc'. Library model specific files have 'func' in their name. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Friday, March 13, 2020 1:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context 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

5 years, 7 months

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

Mate, Thanks for providing your time to respond. Understanding there are two models in play helps a lot. A few follow up questions... Can you confirm that the models are mutually exclusive? This page indicates to me that they are mutually exclusive: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… Or are there provisions to allow a system to run both models on the _same_ execution node? For example running both on the same v7 or v8 with TrustZone core. If there are provisions for this, where can I go to get a better understanding of them? Also, is there any spec for the library model beyond the API descriptions in the CMSIS documentation (https://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RT… If not, then I'll rely on reading the existing code. Please feel free to point me more documentation if I can get answers there. (I don't mind a friendly "read the manual" or "run this example code.") Thanks again for your time. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday, March 12, 2020 2:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context 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

5 years, 7 months

1
0
0 0

Re: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context

by Mate Toth-Pal

Hi Erik, Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up. So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions. The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M): https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Ar… ) In this model, all the secure partitions have a runtime context associated with them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time. 'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this. The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the /** * \brief Stores caller's client id in state context */ void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]); API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients. TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure Service was called from Non-Secure code) Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c. The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting the secure stack pointer to the desired context (hence the "prepare"). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS scheduling. Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Wednesday, March 11, 2020 3:07 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context 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

5 years, 7 months

1
0
0 0

Re: [TF-M] NS DATA Linker file

by Mate Toth-Pal

Hi Andrej, You seem to be right. In the current platforms NS_DATA_SIZE is defined as either of the following: * #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) * #define NS_DATA_SIZE (TOTAL_RAM_SIZE / 2) Which means NS_DATA_SIZE Is the maximum available RAM for the NS Software. So the maximum available size of the RW and ZI data is decreased by the amounts you enumerate in your mail. I created a task to fix this: https://developer.trustedfirmware.org/T687 Thanks, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, March 12, 2020 9:23 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] NS DATA Linker file Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

5 years, 7 months

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas, I have noticed today, that the PSA test suite has done several merges to its master branch. Based the PSA test-suit readme, it has switched to newer versions of the PSA API. Should we try to update or better to wait for a right signal from the TFM team? Thanks, Andrej From: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Sent: Thursday, February 6, 2020 2:09 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Subject: RE: PSA Test Suite - Attestation test Hi Andrej, The v19.08_TBSA0.9 version of psa-arch test suite is aligned with current TF-M master. I have executed the test suite and found that unfortunately the attestation test suite is currently broken: * It was introduced by the QCBOR library update in https://review.trustedfirmware.org/c/trusted-firmware-m/+/2679/6<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> * Currently there is a misalignment between psa-arch and tf-m in terms of QCBOR version. psa-arch still relies on older version of QCBOR. * The version mismatch lead some parsing error in CBOR that is the reason why the test suite is failing. * Other issue is that v19.08_TBSA0.9 version of psa-arch mandates the key-id in unprotected COSE header, however that field is optional according to the standard. In TF-M the inclusion of key-id was bind to ATTEST_INCLUDE_TEST_CODE_AND_KEY_ID, which was split to two compile time switch (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3147<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>) ATTEST_INCLUDE_COSE_KEY_ID and ATTEST_ INCLUDE_TEST_CODE. Way forward: * I let the psa-arch test team to update QCBOR. * Fix will be put on master, but currently the tip of the psa-arch master is not aligned with TF-M master. They are supports different PSA API versions. * In TF-M there is a branch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.trust…> where the PSA API update is happening. This branch is intended to be merged to master in Q1. Tamas From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>> Sent: 05 February 2020 14:21 To: Tamas Ban <Tamas.Ban(a)arm.com<mailto:Tamas.Ban@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: RE: PSA Test Suite - Attestation test Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas 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: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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.

5 years, 7 months

2
3
0 0

Re: [TF-M] TF-M Technical Forum call - March 19

by Mate Toth-Pal

Hi All, I would like to give a short talk about a tool proposal to test IRQ handling in TF-M core. Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, March 11, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 19 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

5 years, 7 months

1
0
0 0

NS DATA Linker file

by Andrej Butok

Hello, It looks like there is a mistake for ER_DATA region in the NS armclang linker file. ... ER_DATA NS_DATA_START NS_DATA_SIZE { * (+ZI +RW) } /* MSP */ ARM_LIB_STACK_MSP +0 ALIGN 32 EMPTY NS_MSP_STACK_SIZE { } /* PSP */ ARM_LIB_STACK +0 ALIGN 32 EMPTY NS_PSP_STACK_SIZE { } ARM_LIB_HEAP +0 ALIGN 8 EMPTY NS_HEAP_SIZE { } ... ER_DATA does not take into account the NS_MSP_STACK_SIZE+NS_PSP_STACK_SIZE+EMPTY NS_HEAP_SIZE size: #define NS_DATA_SIZE (TOTAL_RAM_SIZE - S_DATA_SIZE) Guess, the NS linker file should be: ... ER_DATA NS_DATA_START NS_DATA_SIZE-NS_MSP_STACK_SIZE-NS_PSP_STACK_SIZE-EMPTY NS_HEAP_SIZE { * (+ZI +RW) } ... Or, did I miss something? Thank you, Andrej Butok

5 years, 7 months

1
0
0 0

Cooperative Scheduling Rules and CMSIS tz_context

by Shreve, Erik

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

5 years, 7 months

1
0
0 0

TF-M Technical Forum call - March 19

by Anton Komlev

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

5 years, 7 months

1
0
0 0

Re: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application

by Tamas Ban

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

5 years, 7 months

1
0
0 0

TrustZone initialisation procedure

by Reinhard Keil

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

5 years, 7 months

2
1
0 0

Product Lifecycle Management: TF-M + Non-Secure Application

by Reinhard Keil

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

5 years, 7 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Reed Hinkel

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.

5 years, 8 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Abhishek Pandit

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.

5 years, 8 months

1
0
0 0

TF-M Profile 1 design document under review

by David Hu

Hi all, As we discussed in Tech Forum yesterday, we proposed the TF-M Profile 1 design document on https://review.trustedfirmware.org/c/trusted-firmware-m/+/3598. Any comment, suggestion or question is welcome. We will keep updating and finalizing the document. The corresponding TF-M Profile 1 implementation patch set is also under review on https://review.trustedfirmware.org/q/topic:%22profile-1-config%22+(status:o…. Best regards, Hu Ziji

5 years, 8 months

1
0
0 0

Re: [TF-M] SPM_IDLE

by Ken Liu

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

5 years, 8 months

1
0
0 0

Recent patches

by Thomas Törnblom

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>

5 years, 8 months

1
0
0 0

Entry to TF-M

by Reinhard Keil

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

5 years, 8 months

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - March 5

by Bill Fletcher

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

5 years, 8 months

1
0
0 0

TF-M Technical Forum call - March 5

by Reinhard Keil

Is there a forum call tomorrow? Where can I find the dail-in information?

5 years, 8 months

1
0
0 0

Questions on TFM_NS_CLIENT_IDENTIFICATION

by Reinhard Keil

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

5 years, 8 months

1
0
0 0

SPM_IDLE

by DeMars, Alan

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

5 years, 8 months

1
0
0 0

memcpy variants

by Reinhard Keil

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

5 years, 8 months

1
0
0 0

TrustZone initialisation procedure

by Reinhard Keil

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

5 years, 8 months

1
0
0 0

Re: [TF-M] TrustZone initialisation procedure

by Ken Liu

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.

5 years, 8 months

1
0
0 0

TrustZone initialisation procedure

by Jonatan Antoni

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.

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Andrej Butok

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

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Soby Mathew

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 >

5 years, 8 months

3
2
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by David Hu

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.html https://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

5 years, 8 months

2
3
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

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

5 years, 8 months

1
0
0 0

Call for a feedback on TF-M adaptation experience

by Reinhard Keil

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.html https://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

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

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

5 years, 8 months

1
0
0 0

Re: [TF-M] PSA-Test Suite, 23 Crypto Tests failed

by Anton Komlev

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> On Behalf Of Andrej Butok via TF-M Sent: 28 February 2020 09:46 To: tf-m(a)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

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Kevin Townsend

Hi Anton, One particular difficulty I've encountered working with TF-M for the Zephyr certification demo app, and with the LPC55S69 port to upstream TF-M is the debugging experience with GDB and the dual execution environments. GDB can be quite powerful if you are familiar with it, but there is a definite learning curve, and the S and NS separation and the dual binary images (three with BL2) adds an additional degree of complexity. I think having a dedicated debugging tutorial around GDB would be very useful to people adopting TF-M and perhaps new to GDB, just to show how some basic debugging might happen, how to debug across the NS/S boundary, etc. For example, the '--tui' option for GDB may not be very well known, and it may be useful to highlight (see screenshots at the bottom of this issue: https://github.com/microbuilder/trusted-firmware-m/issues/1) Practical, step-by-step debugging documentation just seems like a good investment to help flatten this inevitable learning curve developing real-world solutions with TF-M? Best regards, Kevin On Thu, 27 Feb 2020 at 13:13, Anton Komlev via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > A kind reminder. > Your feedback is valuable all the time with no deadline defined. > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *Anton > Komlev via TF-M > *Sent:* 07 February 2020 13:13 > *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 > > > > 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) if it’s more > comfortable for you. > > > > Thank you in advance, > > Anton > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 8 months

2
1
0 0

PSA-Test Suite, 23 Crypto Tests failed

by Andrej Butok

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

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - March 5

by David Hu

Hi Anton, I'd like to share about the current design and draft implementation of TF-M Profile 1. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, February 25, 2020 1:11 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - March 5 Dear All, The next Technical Forum is planned on Thursday, March 5 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

Re: [TF-M] Call for a feedback on TF-M adaptation experience

by Anton Komlev

A kind reminder. Your feedback is valuable all the time with no deadline defined. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 07 February 2020 13:13 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 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

5 years, 8 months

1
0
0 0

Re: [TF-M] Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone The below mentioned patches have been merged to TF-M master. The Open CI is also updated to pull in the right version of mbed-crypto (3.0.1) and it should now show results as expected. You may to have rebase your existing patches currently in review if you need to run CI tests. Best Regards Soby Mathew > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-M > Sent: 18 February 2020 11:38 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Update Crypto, SST and Attestation services to the latest > versions > > Hi Everyone, > This is a heads up that there are patches in review which update the Crypto, > SST and Attestation services to latest versions of their respective specifications : > > 1. Crypto-service migration to Mbed Crypto 3.0.1 > > The patches is available here : > https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:ope > n%20OR%20status:merged) > > This migrates the crypto service to the latest implementation of PSA > specification as implemented by mbed-crypto. > > 2. SST: Implement PSA Protected Storage 1.0 > > https://review.trustedfirmware.org/q/topic:%22sst-1.0- > update%22+(status:open%20OR%20status:merged) > > 3. Initial Attestation: Align interface to PSA API 1.0 > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=b8d88ce6fb7c8e7301f32ab7f6b36dd796692f98 > > and > > https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature- > psa-dev-api-update&id=12c02d16958c9dbd57a6bebe6f29b7a207355831 > > These patches are expected to be reviewed and merged back to the master in > the next couple of weeks. > > Best Regards > Soby Mathew > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

TF-M Technical Forum call - March 5

by Anton Komlev

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

5 years, 8 months

1
0
0 0

TF-M

by Konstantinos Chatzis

Hi all, As Anton already announced during last TF-M Tech Forums, we have recently started a deep review initiative for the TF-M project, with main focus to improve User Experience and reduce Onboarding Effort. The team is currently focusing on the following topics: * Repository and Housekeeping * Development Environment * Build System * Source tree structure and Abstraction Layers * Coding Rules * Documentation * Continuous Integration * Testing We are fully aware of the vast area the topics above cover but, focusing on the basic principles mentioned above, we intend to conclude to implementable solutions. It is therefore of significant importance that your individual or team's onboarding experience is shared with us and this mailing list. Please share any feedback based on your experience using and/or enhancing TF-M. Regards, Kostas 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, 8 months

1
0
0 0

TF-M (PSA-Level) Fuzzing Tool

by Gary Morrison

Hi TF-Mers! Sincere apologies for the short notice, but at the next TF-M Tech Forum (in a few hours from now!), I will do a short presentation on a TF-M Fuzzing Tool that I’ve been working on for 2-3 months. Currently, it’s just a prototype, and I’ve only tested SST functionality so far, but we’re hoping we can get it out into the open-source arena soon, and get a little more brain power into improving its capabilities. (Apologies also that it’ll be at 1AM my time, out here in Austin, so please bear with me if I sound a little groggy! 😊) Hope you can join us! -- Gary Morrison gary.morrison(a)arm.com Principal SW Engineer Arm, Inc. Austin, TX. USA

5 years, 8 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - February 20

by Minos Galanakis

Hello all, I will be presenting about the use of "SFN" section for handling object placement in the Secure Side and how this may hide dragons. Regards, Minos Galanakis ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 11 February 2020 12:04 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - February 20 Dear All, The next Open Technical Forum is planned on Thursday, February 20 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

Update Crypto, SST and Attestation services to the latest versions

by Soby Mathew

Hi Everyone, This is a heads up that there are patches in review which update the Crypto, SST and Attestation services to latest versions of their respective specifications : 1. Crypto-service migration to Mbed Crypto 3.0.1 The patches is available here : https://review.trustedfirmware.org/q/topic:%22crypto_update%22+(status:open… This migrates the crypto service to the latest implementation of PSA specification as implemented by mbed-crypto. 2. SST: Implement PSA Protected Storage 1.0 https://review.trustedfirmware.org/q/topic:%22sst-1.0-update%22+(status:ope… 3. Initial Attestation: Align interface to PSA API 1.0 https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… and https://git.trustedfirmware.org/trusted-firmware-m.git/commit/?h=feature-ps… These patches are expected to be reviewed and merged back to the master in the next couple of weeks. Best Regards Soby Mathew

5 years, 8 months

1
0
0 0

Call for review of dual-cpu test cases patches

by David Hu

Hi all, Thanks a lot for the reviews and support for dual-cpu multiple NS PSA client calls feature in TF-M. The patches were merged. Another patch set, which adds test cases for dual-cpu multiple NS PSA client calls, have also been reviewed several rounds in last 2 months, together with feature patches. I’d like to merge the test case patches *by this Thursday* if no further comment. Please help review https://review.trustedfirmware.org/q/topic:%22dualcpu-test-framework%22+(st… if you have interest. Any suggestion or comment is welcome. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Wednesday, February 12, 2020 9:47 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Dual-cpu multiple NS PSA client calls feature Hi all, I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments. The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation. The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform. If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+…. The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… Comments and suggestions are still and always welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 8 months

1
0
0 0

[RFC] Update on SPRTL design document

by Ken Liu

Hi, There is something out of fashion in the first version SPRTL document, and the content is not well-formatted in a not ideal place. I updated parts of the document: - Re-format the document. - Fixes the descriptions for C runtime API, now we are re-using the headers, types and parts of toolchain library if possible. - Important change: Define a new 'SP Scratch' area and needs SPM cooperation to let the SPRTL can retrieve SP specific metadata. The new SP scratch area is used for resolving the context-based runtime API cannot retrieve the SP metadata problem since SPRTL is just a code. With this change, the SPRTL has a way to retrieve the SP metadata and then context-based runtime API is much easier in implementation. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3457 And the issue: https://developer.trustedfirmware.org/T484 Thanks. /Ken

5 years, 8 months

1
0
0 0

Invitation: TF-M Tech Forum @ Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h When: Every 2 weeks from 07:00 to 08:00 on Thursday from Thu 20 Feb to Fri 27 Mar United Kingdom Time Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MnZtamowZG5xZXQzNDdrZ… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 8 months

1
0
0 0

Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Andrej Butok

Hi Ken, Yes, we are using L2. I have just switched to the latest commit which includes the suggested fix. But tfm_nspm_thread_entry() still goes to the MemManage_Handler() fault a bit later on "push {r0, r1} \n" Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 21, 2020 6:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit 'cba90782908626f955fe361f803558181a85c6fc' fixes this problem. /Ken 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: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It's good to know if this is something known or met before. Thank you, Andrej

5 years, 8 months

2
2
0 0

Dual-cpu multiple NS PSA client calls feature

by David Hu

Hi all, I’d like to submit the patches to enable multiple NS PSA client calls feature on dual-cpu system *by this week*, if no more comments. The patches have been reviewed for several rounds in last two months. Thanks a lot for all your reviews, comments and validation. The patch set can support NS side to start multiple outstanding PSA client calls concurrently, on dual-cpu system. The feature is enabled and verified on Cypress PSoC 64 platform. If you are interested, please take a look at https://review.trustedfirmware.org/q/topic:%22dualcpu-multi-client-call%22+…. The overall design is discussed in design documents https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… and https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/design_doc… Comments and suggestions are still and always welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 8 months

1
0
0 0

Re: [TF-M] mbed-crypto version

by Andrej Butok

You may ping here: https://developer.trustedfirmware.org/T561 From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Tuesday, February 11, 2020 1:23 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] mbed-crypto version Are there any plans to upgrade from mbed-crypto-1.1.0 to the latest? There are some IAR specifics I would like to update in CMakeLists.txt for mbed-crypto, but as the version required by tf-m is very old, I don't see that it would help if I update the current version. 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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iar.co…> Twitter: www.twitter.com/iarsystems<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twitte…>

5 years, 8 months

1
0
0 0

mbed-crypto version

by Thomas Törnblom

Are there any plans to upgrade from mbed-crypto-1.1.0 to the latest? There are some IAR specifics I would like to update in CMakeLists.txt for mbed-crypto, but as the version required by tf-m is very old, I don't see that it would help if I update the current version. 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, 8 months

1
0
0 0

TF-M Technical Forum call - February 20

by Anton Komlev

Dear All, The next Open Technical Forum is planned on Thursday, February 20 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Best regards, Anton Komlev

5 years, 8 months

1
0
0 0

Re: [TF-M] Test: Update test framework API

by Jamie Fox

Hi Devaraj, Happy to merge it for you, but first please can you add a comment to the gerrit review with details of testing done for the patch? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: 10 February 2020 09:50 To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] Test: Update test framework API Hi TF-M maintainers, It looks like there is no objection to the patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172. Can you please merge it? Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Devaraj Ranganna via TF-M <TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>> Reply to: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com<mailto:Devaraj.Ranganna@arm.com>> Date: Tuesday, 4 February 2020 at 16:30 To: "TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>" <TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>> Subject: [TF-M] Test: Update test framework API Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the patchset be merged? Thanks, Dev 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.

5 years, 8 months

2
2
0 0

Re: [TF-M] Changes to OS wrapper

by Kevin Peng

Hi Vikas, I'm seeing two topics here if I understand correctly. The first one is how to deal with memory management in the os wrapper implementation. The second one is how to safely "exit" and "delete" a child thread. Please first check if my understanding is correct. For the first topic, except the handles of threads, semaphores or mutex (which are the OS handles I guess), the OS wrapper needs some extra handles for resource handling. For example the pointer of the memory allocated in the OS wrapper API. The two handles forms the new OS wrapper handle you proposed. For the second topic, can we just terminate or delete the child thread by itself after it has done its job? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: Friday, February 7, 2020 12:55 AM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com>; Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi all, Thanks for the e-mail. I would like to highlight a few issues with the current API implementation. * It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use. * The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. So a change in the API implementation is required to address the above issues. * Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources. * Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle. Comments towards the arguments: * If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption. * If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything. * If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here: * It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further. * If the thread exits then os_wrapper_thread_delete(handle) will result in error. * If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here: * Adds an additional maintainability burden. * Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use. * It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information. Depreciating the old API will ensure the following: * Future applications are portable to any OS that needs manual memory management. * It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management. * The in-tree applications will be refactored as part of this API change. Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M? Thanks & Best Regards, Vikas Katariya 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: Thursday, February 6, 2020 12:16 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] Changes to OS wrapper Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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.

5 years, 8 months

2
3
0 0

Re: [TF-M] Test: Update test framework API

by Devaraj Ranganna

Hi TF-M maintainers, It looks like there is no objection to the patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172. Can you please merge it? Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Devaraj Ranganna via TF-M <TF-M(a)lists.trustedfirmware.org> Reply to: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Date: Tuesday, 4 February 2020 at 16:30 To: "TF-M(a)lists.trustedfirmware.org" <TF-M(a)lists.trustedfirmware.org> Subject: [TF-M] Test: Update test framework API Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the patchset be merged? Thanks, Dev 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.

5 years, 8 months

1
0
0 0

Re: [TF-M] Linking issues with SFN section

by Ken Liu

Hi, Now we just put code and RODATA into SFN so it works. And your concern really exists - for example, if a string is applied during SFN function, the string is actually out of SFN range and we need to put this string variable into SFN, too. The SFN area should be simplified later one and SFN section should be removed (apply specific section to symbol should be restricted, only some special purposes like init-table usage are allowed). Instead, an overall library should be put in TFM_UNPRIV_CODE and with this: ?.lib (+RO) should work for your case - does IAR support this scenario with some a.lib (+RO) or it supports .o files only? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, February 7, 2020 7:11 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Linking issues with SFN section I would like to discuss the use of the SFN section for the secure image. During my port of tf-m to the IAR toolchain I ran into issues related to the SFN section. There are quite a few functions that are placed in the SFN section, which is then linked into the TFM_UNPRIV_CODE block. I don't know how armclang or gcc handles this, but the IAR compiler may generate .rodata initializers, which does not end up in the SFN section, predominantly the in_vec and out_vec structs with debug builds. I've had to manually add the .rodata sections from these object files (tfm_*_secure_api.o) to the TFM_UNPRIV_CODE in the tfm_common linker script in order to work around MemManage_Handler traps. I would like to suggest that the relevant files are added to the relevantï¿½ block in the tfm_common.* linker script instead of using the SFN section. That way one can specify that both the .text (ro code) and .rodata (const) goes into the same block. Comments? 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, 8 months

1
0
0 0

Re: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4?

by Thomas Törnblom

Turns out the issue was with the timer interrupt routine clobbering a register when compiled with no optimization. I have a workaround, but I’m also working with the compiler developers on what the proper behavior is. Thomas Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1<x-apple-data-detectors://6/1> SE-750 23 Uppsala, SWEDEN<x-apple-data-detectors://6/1> Mobile: +46 76 180 17 80<tel:+46%2076%20180%2017%2080> Fax: +46 18 16 78 01<tel:+46%2018%2016%2078%2001> 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> 6 feb. 2020 kl. 09:56 skrev Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>: How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Call for a feedback on TF-M adaptation experience

by Anton Komlev

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

5 years, 8 months

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Vikas Katariya

Hi all, Thanks for the e-mail. I would like to highlight a few issues with the current API implementation. * It isn't good for OS which relies on manual memory management, the current API doesn't give an opportunity to free any resources which were in use. * The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources to be freed which are not managed by the OS. So a change in the API implementation is required to address the above issues. * Use `os_wrapper_current_thread_suspend()` and `os_wrapper_thread_terminate(handle)` API, ensuring we suspend and terminate safely, enabling it to free allocated resources. * Remove `os_wrapper_get_handle()` to make sure we differentiate between OS wrapper handle and OS handle. The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle because implementations can't always create an OS-wrapper handle from an OS handle. Comments towards the arguments: * If we go with `os_wrapper_thread_exit()` to exit a child, then OS can allocate that resource to another purpose instantly and if we were to pass that handle to `os_wrapper_thread_delete(handle)`, we still risk corruption. * If we go with `os_wrapper_thread_exit()` suspending the thread Or `os_wrapper_thread_delete(handle)` performing a NOP, it changes the semantics of what API intends to do and is not a natural way of moving forward. Also, it may confuse developers by making exit suspend instead of exit, or delete not delete anything. * If we go with `os_wrapper_thread_exit()` performing a NOP and `os_wrapper_thread_delete(handle)` performing a termination of the thread, there are few things to consider here: * It changes the semantics again for exit, but on some OS if the thread has finished its operations it will either exit or suspend itself as there is nothing to execute further. * If the thread exits then os_wrapper_thread_delete(handle) will result in error. * If we add a wrapper variable that captures info on if the thread has been exited to check deletion is safe or not, there few things to consider here: * Adds an additional maintainability burden. * Tracking if a thread has been exited or not adds a cost in RAM that would not be needed if the API had a good shape. Seeing as we all develop for embedded devices here, we should be very careful with RAM use. * It can't figure out its identification because the OS-wrapper handle is not passed in `os_wrapper_thread_exit()`. Differentiating between the right handle is required to ensure we track the right thread information. Depreciating the old API will ensure the following: * Future applications are portable to any OS that needs manual memory management. * It forces out-of-tree applications using the wrappers to know they need to make a change in order to be portable to operating systems that require manual memory management. * The in-tree applications will be refactored as part of this API change. Further, if there is a matter of handling deprecation of API, then I would like to know how that can be achieved in TF-M? Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, February 6, 2020 12:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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.

5 years, 8 months

2
1
0 0

Linking issues with SFN section

by Thomas Törnblom

I would like to discuss the use of the SFN section for the secure image. During my port of tf-m to the IAR toolchain I ran into issues related to the SFN section. There are quite a few functions that are placed in the SFN section, which is then linked into the TFM_UNPRIV_CODE block. I don't know how armclang or gcc handles this, but the IAR compiler may generate .rodata initializers, which does not end up in the SFN section, predominantly the in_vec and out_vec structs with debug builds. I've had to manually add the .rodata sections from these object files (tfm_*_secure_api.o) to the TFM_UNPRIV_CODE in the tfm_common linker script in order to work around MemManage_Handler traps. I would like to suggest that the relevant files are added to the relevant block in the tfm_common.* linker script instead of using the SFN section. That way one can specify that both the .text (ro code) and .rodata (const) goes into the same block. Comments? 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, 8 months

1
0
0 0

Re: [TF-M] PsoC64 build broken

by Christopher Brand

So the patch does the wrong thing anyway - it effectively changes the watermark assertion so that it won't trigger if the TFM_RAM_CODE area goes beyond the end of RAM. That's just broken, because TFM_RAM_CODE is, obviously, supposed to be in RAM. There may well be a problem here, but this is not the correct fix for it. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:58 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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. 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. 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. 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, 8 months

3
2
0 0

Re: [TF-M] PsoC64 build broken

by Christopher Brand

I did an armclang build of the head of master and with this patch reverted, and there is a small difference between them - the TFM_RAM_CODE and SRAM_WATERMARK sections are swapped. That feels wrong, because the TFM_RAM_CODE is inside SRAM, so I'd expect the "end of SRAM watermark" to be after it, not before it. I'm not sure exactly how the watermark section is used, though. On the plus side, TFM_RAM_CODE does indeed still end up at the correct address, in SRAM. I'm not sure exactly which sections you want me to try changing to set the LMA. The line numbers don't seem to match up... Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Thursday, February 6, 2020 3:43 PM To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [TF-M] PsoC64 build broken CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I'd really prefer to see the patch reverted first, and then we can figure out exactly what's going on and push a revised patch that achieves the objectives without breaking anything. It does seem to have some side-effects on the PSoC64 armclang build, too. It's pretty standard open source process to revert a patch that breaks something like this... Chris From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Thursday, February 6, 2020 3:15 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Christopher Brand <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: PsoC64 build broken Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com<mailto:Gabor.Abonyi@arm.com>> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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. 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. 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, 8 months

1
0
0 0

Re: [TF-M] PsoC64 build broken

by Jamie Fox

Hi Chris, Sorry about that. It shouldn't have changed the address of the region though because it's explicitly set to S_RAM_CODE_START. I think this could be down to an "interesting" behaviour in GCC linker scripts where if the LMA is explicitly set with for a region with "AT>", then it won't revert back to being equal to the VMA for the next region in some cases. So before we revert the change, please can you try setting the LMA explicitly for the following region(s)? That is, try "> FLASH AT> FLASH" instead of just "> FLASH" on lines 527 and 563. Best wishes, Jamie ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Christopher Brand via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 06 February 2020 20:11 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: Gabor Abonyi <Gabor.Abonyi(a)arm.com> Subject: [TF-M] PsoC64 build broken Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 (“Build: Fix SRAM sanity check in common scatter file”) seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I’m quite surprised that the comments on the review note that “I noticed that this define is currently only used for PSOC6 platform which I don't possess” and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven’t dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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, 8 months

2
1
0 0

PsoC64 build broken

by Christopher Brand

Hi, Commit 52182bc5e006752a4d28c3ccd909f93dafee0cf5 ("Build: Fix SRAM sanity check in common scatter file") seems to break the PSoc64 build. This is from https://review.trustedfirmware.org/c/trusted-firmware-m/+/3333 Building with gcc, I get: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/build_gcc_psoc64/secure_fw/tfm_s.ld.i:352 cannot move location counter backwards (from 000000000802f578 to 0000000008000000) collect2: error: ld returned 1 exit status secure_fw/CMakeFiles/tfm_s.dir/build.make:210: recipe for target 'unit_test/tfm_s.axf' failed I'm quite surprised that the comments on the review note that "I noticed that this define is currently only used for PSOC6 platform which I don't possess" and yet apparently a Musca B1-only build was considered sufficient to merge it. I haven't dug into the details, but superficially it seems to move the .ramfunc code to before S_DATA_START, which means that it will no longer be in secure RAM. Can we please revert this patch for now? Chris 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, 8 months

1
0
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi Ken, I’d prefer that TF-M keep exporting the pre-compiled archive for regression tests. The rational behind that is less files to be added/maintained by NS RTOS. Considering this, I think quick and easy way to solve this is for NS RTOS to implement ` tfm_log_printf ` using the print method available. This way no changes are needed in TF-M. I thought about platform-specific shim layer, like adding a new print function “ns_log_printf” to the OS wrapper (app/os_wrapper_cmsis_rtos_v2.c) and use that for NS regression tests. I believe it’s not worth the effort and also it will add another layer of indirection. To summarise, we’ll implement `tfm_log_printf ` in Mbed OS which should resolve the linker issue. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Wednesday, 5 February 2020 at 04:50 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Devaraj, Thanks for the clarification. Looks like this issue is caused by the way the building system integrates the test package with NS RTOS - if source-level integration is applied then the modification is not a problem and this should be the better way - even if we recover the 'printf' implementation, for those RTOS who has no printf, it would be another issue. I think the possible solutions can be: * If we keep using the pre-compiled archive, then some platform-specific shim layer needs to be available to provide platform-specific functions. * If we changed to source-level integration then things would be easier. * A quick way is as you requested, recover back to 'printf'. For the 3rd point, there are some pre-actions to be done: * Make sure the compiler optimization function is limited for easier the implementation of these stdio functions. There is a leading patch for this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3217 * Define the HAL functions for output so that the printf implementation is not CMSIS specific. May I ask how you fix this issue? /Ken ________________________________ From: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Sent: Tuesday, February 4, 2020 11:16 PM To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi Ken, Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`. Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework. Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive. It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi, Why the title is ‘linker issue’ since it is discussing about the printf things? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TF-M NS regression tests - linker issue Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks Thanks, Dev 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, 9 months

2
1
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Andrej Butok

Hi Tamas > Could you tell what was the values of these compile time switches in your test? For the previous TFM, we have used INCLUDE_TEST_CODE_AND_KEY_ID. For the current TFM it was renamed to INCLUDE_TEST_CODE. Other parameters are new, so I have tried different combinations of these parameters, but the PSA Test-Suite Attestation is still failed. > Further do you implemented the boot data sharing between bootloader and runtime firmware? It's used the TFM template code without change from tfm\platform\ext\common\template > Do you sign SPE and NPSE images together or they are signed separately? We do not use the secondary bootloader so far, so image is not signed. As the Attestation Regression tests are passed. It's good to know what combination of parameters have to be used to generate the same token as it was generated by the older TFM and accepted by the PSA Test Suite (last commit on master branch). Or the PSA Test Suite is obsolete. Thank you, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Wednesday, February 5, 2020 1:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Test Suite - Attestation test Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas 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: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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, 9 months

2
1
0 0

Re: [TF-M] Changes to OS wrapper

by Anton Komlev

Hello, Agree with Jamie seeing not enough arguments for extension of existing API. Looks like the required functionality can be hidden inside a specific os_wrapper, which is a main purpose of it. @Vikas, could you explain a bit differently why you are blocked with the current API? Cheers, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 06 February 2020 09:10 To: Vikas Katariya <Vikas.Katariya(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>>; 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] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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, 9 months

1
0
0 0

Re: [TF-M] Persistent keys in the Crypto service

by Kevin Townsend

Hi Jamie, This aligns well with a key requirement we identified thinking about late binding devices that make use of TF-M, such as with cloud services or providers which tend to use X.509 certificate chains which will need to be signed, and a private key generated and held in secure storage as part of the binding and certification signing process. Some initial thoughts are visible here in interim if it's useful to see a use case for this work: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md Best regards, Kevin On Tue, 4 Feb 2020 at 14:32, Jamie Fox via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > I have pushed for review patches to enable persistent keys in the TF-M > Crypto service. With these changes, persistent keys will be stored by Mbed > Crypto using the ITS APIs exposed by TF-M. > > > > The reviews are here: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 > (implementation) > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests) > > > > Currently, merging of these patches is blocked as they depend on Mbed > Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs > exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in > progress. > > > > If anyone wants to test these patches in the meantime, it is possible to > cherry pick the patch in the Mbed Crypto repo that adds support for ITS > 1.0.0. With the Mbed Crypto repo checked-out at the “mbedcrypto-1.1.0” tag, > do a “git cherry-pick bda5a2111” to cherry pick the relevant patch. > > > > Kind regards, > > Jamie > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 9 months

1
0
0 0

Re: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4?

by Mate Toth-Pal

Hi Thomas, A brief description of this test scenario is in docs\user_guides\services\core_test_services_integration_guide.rst: <quote> - S code waits for an interrupt (calling ``psa_wait()``), the handler is in the service that is waiting, ``psa_eoi()`` is called after ``psa_wait()`` returns (``IRQ_TEST_SCENARIO_4``) <end quote> ConfigRegression.cmake is using the library model, so that implementation needs to be considered. In this scenario only a secure interrupt is involved. The sequence is the following (only relevant code parts are mentioned): 1. spm_irq_test_1_prepare_test_scenario_internal() starts the secure timer. 2. spm_irq_test_1_execute_test_scenario() enters a while loop, waiting the signal for the timer to be set call psa_wait(SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ, PSA_BLOCK); 3. at some point the interrupt is triggered, and the signal is set for the interrupt. The interrupt handler is run, and it sets a flag timer0_triggered. SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ_isr() is the interrupt handler function in this case, and this function executes an explicit "DSB" instruction to be sure that the write to the flag is committed. (The flag is declared as volatile) 4. When the function spm_irq_test_1_execute_test_scenario() exits the loop, it calls pas_eoi(), and returns. At the moment I don't see a flaw in this scenario, which of course gives no guarantee that there isn't a flaw in it somewhere. We often test TF-M in FVP, and found that from time to time the FVP runs slower (seems to be executing less cycles per minute) than usual. In this cases IRQ testcases appeared to be hanging, although if we waited for the necessary number of cycles to be executed by the FVP, these tests always passed. Did you have a chance to have a look at it with a debugger? If so, where exactly is the execution stucked? Have the interrupt been triggered as expected? Regards, Mate From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Thursday, February 6, 2020 9:56 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Possible race condition in IRQ_TEST_SCENARIO_4? How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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, 9 months

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Gyorgy Szing

Hi, >From the architecture point of view, when an "owner" (sw entity) defines an API, the best is to do that based on it's own needs. This gives the most flexibility and makes the API best withstand future challenges. Sometimes this is not possible. An example for this is the TRIM functionality of SSD storage, where the file-system must give extra information to the storage. In this case the extension of the API is driven by the implementation and thus implementation details. This is risky as different implementations may have conflicting needs, and sometimes the API cannot fulfill both. If your case, a possible solution is to implement the os_theread_delete() and an empty function. If that is not possible, then a wrapper can be added where a variable captures info on if the thread has been exited, and thus if deletion is safe or not. If it is, then os_thread_delete() can exit without doing anything. The call sequence of suspend and the delete is specific to the OS you are using or to the way you use it. Do you think does here a strong reason exist to go for an API extension driven by the implementation? I don't have all details, but as far as I understand the specific cases you described I don't see an imminent need for the API change. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 06 February 2020 08:47 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Changes to OS wrapper Hi Jamie, Thanks for getting back. It's because of os_wrapper_thread_exit() is used to exit the child thread in the SST test, which means the handle is no longer valid for os_wrapper_thread_delete() to operate on, resulting in an error. The ideal way to do this properly is to use os_wrapper_thread_suspend() and then os_wrapper_thread_delete() from the parent thread. Thanks & Best Regards, Vikas Katariya From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Wednesday, February 5, 2020 17:16 To: Vikas Katariya <Vikas.Katariya(a)arm.com<mailto:Vikas.Katariya@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Changes to OS wrapper Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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. 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, 9 months

1
0
0 0

Possible race condition in IRQ_TEST_SCENARIO_4?

by Thomas Törnblom

How is the IRQ_TEST_SCENARIO_4 supposed to work? I suspect that there might be a lurking race condition somewhere in that test. Some, not all, of the (M33/M23) targets gets stuck in that test when the ConfigRegression.cmake config is built with IAR in Debug mode. If I build it with RelWithDebInfo then the test runs OK for all applicable targets. No problems with Debug builds for the other configurations. Occasionally the test will run successfully also for a normally problematic target if I run it in the debugger and stop execution at breakpoints, but it is very random, which is why I suspect there might be a race problem. 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, 9 months

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Jamie Fox

Hi Vikas, I still do not really understand the rationale for these changes. If dynamic memory allocation inside the os_wrapper shim is really what you want to do, then what is stopping you from implementing the following? os_wrapper_thread_new() { malloc(external_to_os_resource) /* create thread */ } os_wrapper_thread_delete() { free(external_to_os_resource) } Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: 05 February 2020 10:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Changes to OS wrapper Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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.

5 years, 9 months

2
1
0 0

Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode"

by Ken Liu

I have created the patch for this issue: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3359 The non-secure entry thread re-uses the same context and stack of initial booting thread, while initial booting thread would update the context in stack while SVC to SPM initialization. The context needs to be reset after SPM initialized all threads, and the EXC_RETURN is missed during the reset process. If initial thread is executed with FP active, the EXC_RETURN generated by SVC would be 0xFFFFFFED, and cause extra 0x48 bytes to be popped while exiting from exception which causes the error. This patch resets the EXC_RETURN to 0xFFFFFFFD. Please help to comment, thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, January 22, 2020 10:29 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I double checked in my platforms and looks fine, so you are porting them to your board, right? I have created a task for detailed description, let’s discuss the details there: https://developer.trustedfirmware.org/T652 Thanks. /Ken From: Andrej Butok <andrey.butok(a)nxp.com> Sent: Tuesday, January 21, 2020 11:19 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Ken, Yes, we are using L2. I have just switched to the latest commit which includes the suggested fix. But tfm_nspm_thread_entry() still goes to the MemManage_Handler() fault a bit later on "push {r0, r1} \n" Thanks, Andrej From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: Tuesday, January 21, 2020 6:05 AM 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] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hi Andrej, I guess you are using the level2 configuration. This fault was caused by tfm_nspm_thread_entry is trying to call a function in the privileged area. This commit ‘cba90782908626f955fe361f803558181a85c6fc’ fixes this problem. /Ken 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: Tuesday, January 21, 2020 12:14 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Stuck in tfm_nspm_thread_entry() after "Initialize IPC SPM in handler mode" Hello, Just want to check if this is a known issue. During synchronization to the latest TFM, TFM applications are stuck in the exception handler tfm_nspm_thread_entry ()=>MemManage_Handler(). This issue has been caused by commits (3.1.2020): 1. Revision: 5248af2d7b86775364a0e131eb80ac0330bc81fb Message: Core: Use naked function for ns jumping 1. Revision: 490281df3736b11b62e25bc98d3e2c6e4e10478c Message: Core: Initialize IPC SPM in handler mode The previous commit is fully OK (committed 2.1.2020): Revision: 93dabfd3a35faf9ed88285e09997491e93cefa5c Message: Core: Trigger a system reset for programmer error The commits do not have any changes in the linker files and no changes in target files, only the common and ARMv8 code. It’s good to know if this is something known or met before. Thank you, Andrej

5 years, 9 months

1
0
0 0

Re: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Anton Komlev

Hi Jonatan, All, Thanks for proposing the topic inline with the thread on flash_layout.h and region_defs.h configuration header. Let's discuss it tomorrow. All the best, Anton Komlev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jonatan Antoni via TF-M Sent: 05 February 2020 14:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Topic proposal for upcoming Open Tech Forum: CMSIS-Zone Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html 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.

5 years, 9 months

1
0
0 0

Topic proposal for upcoming Open Tech Forum: CMSIS-Zone

by Jonatan Antoni

Hi all, I'd like to propose to give you a short live presentation (10-15 minutes) of CMSIS-Zone [1]. In Arm DSG we are developing and using CMSIS-Zone to gather required memory partitioning data and generate consistent config file (such as partition headers, SAU/MPC/PPC configs, MPU configs, scatter files, etc). Robi made good progress aligning TF-M with Arm's tool ecosystem, such as componentization for shipping CMSIS-Packs. He used CMSIS-Zone to generate the required config files for TF-M. In my presentation I'd like to focus on configuring TF-M for NXP's LPC55 using CMSIS-Zone. Cheers, Jonatan Antoni Senior Engineering Manager - CMSIS [Germany on Google Android 8.0] [United Kingdom on Google Android 8.0] [1] https://arm-software.github.io/CMSIS_5/Zone/html/index.html 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.

5 years, 9 months

1
0
0 0

Re: [TF-M] PSA Test Suite - Attestation test

by Tamas Ban

Hi Andrej, Could you tell what was the values of these compile time switches in your test? I assume you did the test on NXP board. Further do you implemented the boot data sharing between bootloader and runtime firmware? Do you sign SPE and NPSE images together or they are signed separately? Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 04 February 2020 17:33 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Test Suite - Attestation test Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok 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, 9 months

1
0
0 0

Invitation: TF-M Tech Forum @ Thu 6 Feb 2020 17:00 - 18:00 (GMT) (tf-m@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-M Tech Forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/──… Fletcher is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/5810428000Meeting ID: 581 042 8000One tap mobile+16465588656,,5810428000# US (New York)+16699009128,,5810428000# US (San Jose)Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-freeMeeting ID: 581 042 8000Find your local number: https://zoom.us/u/aerUYXPhSL────────── When: Thu 6 Feb 2020 17:00 – 18:00 United Kingdom Time Where: https://zoom.us/j/5810428000 Calendar: tf-m(a)lists.trustedfirmware.org Who: * Bill Fletcher- organiser * tf-m(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGxvN2syYWc0ZWV1NXFia… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 9 months

1
0
0 0

Re: [TF-M] Changes to OS wrapper

by Vikas Katariya

Hi all, The patch set has been updated with further changes: * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 OS wrapper layers help to create Mutex, Semaphores, and Thread on an OS. The wrapper was designed to be implemented on platforms that dynamically allocate memory or objects from a predefined OS memory pool. The current shape of the OS wrapper is not a good fit for work with operating systems that require manual memory management. For example, if the child thread created in ns_test_helpers.c does a simple os_wrapper_thread_exit(), this does not give any opportunity for manually-managed thread resources to be freed; this leads to a memory leak. Therefore os_wrapper_current_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where manual memory management is required. The removal of os_wrapper_thread_exit() is warranted as it encourages applications to avoid memory leak scenarios by requiring applications to remember to call os_wrapper_thread_terminate(). If we were to keep os_wrapper_thread_exit() around, this would impose undue cognitive overhead on wrapper users by making os_wrapper_thread_exit() do something other than exit the current thread (on platforms requiring manual memory management); an os_wrapper_thread_exit() implementation could not actually exit a thread on a manual memory managed OS, as the thread must remain valid until clean up time, and exiting the thread would invalidate the OS's thread resource. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3299 These changes reflect to avoid memory leaks on operating systems that use manually managed dynamic memory allocation but not from static memory/objects pools, allowing them to free after usage. Remove "get_handle" because it's not possible to implement it efficiently on systems that require manual memory management. The os-wrapper handle must be different from the actual underlying OS handle on a manually-memory-managed system in order to allow the resources be freed which are not managed by the OS. For example: struct { os_handle; external_to_os_resource; }; The os-wrapper knows more about the resources being managed than the OS itself. It is supposed to return an OS Wrapper handle than OS handle, because implementations can't always create an os-wrapper handle from an OS handle. In this case the os-wrapper handle could be a pointer to this struct, but could not be just the os_handle directly. Further os_wrapper_current_thread_get_priority() is used to avoid confusion between the top and bottom layer handles, because the older implementation can refer to different object types when operating across multiple layers. * https://review.trustedfirmware.org/c/trusted-firmware-m/+/3347 - Improves test efficiency. Please review and share your thoughts. Thanks & Best Regards, Vikas Katariya From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Vikas Katariya via TF-M Sent: Monday, January 27, 2020 15:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] App: Changes to OS wrapper Hi all, I am proposing new changes to OS wrapper layer to help other RTOS use dynamic memory allocation. OS wrapper layers help to create Mutex, Semaphores, and Thread on RTOS. The wrapper is designed to use static allocation of memory/objects from predefined OS memory pool, which is not fully featured enough to allow dynamic memory allocation and freeing them after completion, if an RTOS requires that kind of implementation. For example, the child thread created in ns_test_helpers.c does a simple exit without passing a handle if the memory was dynamically allocated, which is a memory leak scenario. Therefore os_wrapper_thread_suspend() and os_wrapper_thread_delete() are introduced to aid scenarios where dynamic memory allocation and freeing is required. In the current patch we just suspend the child thread and terminate it from parent thread. The patch is open for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3294 Thanks & Best Regards, Vikas Katariya 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.

5 years, 9 months

1
0
0 0

MPS3/AN524 assistance requested

by Thomas Törnblom

To finish off the IAR port of TF-M I've added the MPS2 and MPS3 targets. The MPS2 targets works fine, but I need some assistance with getting the MPS3/AN524 port to run. I've followed the tfm_user_guide.rst, but I can't get it running with ARMCLANG or gcc either, so I suspect there is something I've missed. The board runs the an524 selftest successfully, and it shows an image on the display as well as produces output on one of the USB serial ports when I configure the board for this. I added the REMAP options described in the user guide to /MB/HBI<BoardNumberBoardrevision>/AN524/an524_v2.txt (the doc mentions v1) I updated the image.txt file with the suggested lines, except for the IMAGE0UPDATE/IMAGE1UPDATE: AUTO lines, which caused a boot error. I tried AUTOQSPI, but settled on NONE. The LOG.TXT file shows no errors What am I missing? 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, 9 months

1
1
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi Ken, Currently, TF-M build process creates an pre-compiled archive of NS tests and exports it. But the implementation of `tfm_log_printf` is not exported. This causes a linker issue when NS tests archive is linked with NS RTOS, which is the reason why subject of this mail contains `linker issue`. Having said that, exporting `tfm_log_printf` won’t solve the problem because `tfm_log_printf` assumes availability of CMSIS driver framework. Also the latest suggestion on the ticket https://developer.trustedfirmware.org/T664 `And I think if you forward the TEST_LOG to your OS printf implementation then everything would be fine?` won’t help because of pre-compiled archive. It looks like only possible solution for NS RTOS is to implement ` tfm_log_printf `. Please do recommend if you have any other ideas. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> Reply to: Ken Liu <Ken.Liu(a)arm.com> Date: Saturday, 1 February 2020 at 04:46 To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M NS regression tests - linker issue Hi, Why the title is ‘linker issue’ since it is discussing about the printf things? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TF-M NS regression tests - linker issue Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks Thanks, Dev 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, 9 months

2
1
0 0

PSA Test Suite - Attestation test

by Andrej Butok

Hello, After upgrade to the latest version of TFM, the Attestation test from the PSA Test Suite is failed (but the TFM Attestation regression tests are passed). What combination of configuration parameters must be used (INCLUDE_OPTIONAL_CLAIMS, INCLUDE_TEST_CODE, INCLUDE_COSE_KEY_ID, BOOT_DATA_AVAILABLE) to follow PSA Test Suite expectations? What commit of the PSA Test-suite must be used for the latest TFM? We are still on the 2019-07-25 (c80681ed7c7f3e2cbf02ded1ef2464ba2ca7ccd5) commit, which was OK with 2-month old TFM. Is the PSA Test Suite Attestation test valid for the latest TFM? Thank you, Andrej Butok

5 years, 9 months

1
0
0 0

Test: Update test framework API

by Devaraj Ranganna

Hi, Currently the test framework which executes test suites doesn't return anything. Therefore it is not possible for application layer to know the status of test cases. The patchset https://review.trustedfirmware.org/c/trusted-firmware-m/+/3172 is intended to export the test case pass/fail status to application layer and beyond (if any test framework is used by Non-secure side). If there are no objections then can the patchset be merged? Thanks, Dev 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, 9 months

1
0
0 0

Re: [TF-M] Exporting flash_layout.h and region_defs.h

by Devaraj Ranganna

Hi, Can we agree on exporting both `flash_layout.h and region_defs.h` till a decision is made on tooling to be used/developed for device config and export in TF-M? Exporting these files doesn’t mean that NS RTOS is obligated to use these rather just a choice. If NS RTOS decides to write/generate their own then these files will just be in the TF-M export folder. Thanks, Dev From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <TF-M(a)lists.trustedfirmware.org> Reply to: Anton Komlev <Anton.Komlev(a)arm.com> Date: Monday, 3 February 2020 at 17:00 To: "TF-M(a)lists.trustedfirmware.org" <TF-M(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi Robert, I see two topics mixing together in this discussion: 1. Project configuration methods/strategy 2. Tooling for that The CMSIS-Zone addresses both of the items somehow. Believe it would be beneficial if you could summaries the thoughts and bring this important topic for discussion on the upcoming Open Technical forum on Feb 6. This would be a good opportunity to present CMSIS-Zone and get a feedback from the community. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 03 February 2020 09:50 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi Robert, “It is a standalone utility that can be used also from command-line. “ The homepage says this is the command to run it “headless”: eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless. There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…). This is not really helping us for now, hopefully this changes in the future. /George From: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>> Sent: 03 February 2020 09:27 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi Gyorgy, Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way. CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world. It is a standalone utility that can be used also from command-line. Best regards, Robert From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Monday 3 February 2020 09:05 To: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi, Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible. What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue. And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side. There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi, I don’t believe this is the right approach. TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side. While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack. There should be a clean separation of files between the secure and non-secure side. The mentioned header files should not be imposed to the non-secure side. Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately. One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: [TF-M] Exporting flash_layout.h and region_defs.h Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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.

5 years, 9 months

1
0
0 0

Re: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Thomas Törnblom

Hi Tamas, The failed tests are: --- DoubleAsSmallestTest FAILED (returned -3 ) HalfPrecisionAgainstRFCCodeTest FAILED (returned -3 ) --- Cheers, Thomas Den 2020-02-04 kl. 14:49, skrev Tamas Ban via TF-M: > > Hi Thomas, > > An extra logging can be enabled for QCBOR test cases: > https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb… > > Could you repeat the test with enabled logs, just to know exactly > which test cases are failing? > > The QCBOR library is used for attest token creation, but only a small > part of the library which is actually used. The IEEE 754 part of QCBOR > is unused in TF-M. So it is not affecting TF-M code, we can > temporarily disable those test cases. It is not a blocking issue for > IAR support. > > I put Laurence on cc he is the maintainer of QCBOR library, I think he > will be interested in the issue. > > Tamas > > *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Thomas Törnblom via TF-M > *Sent:* 04 February 2020 14:01 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues > > The IAR port of TF-M is mostly done and all regression tests runs OK, > with the exception of some of the QCBOR tests. > > I've analyzed the issue to be the NaN tests to not follow the Arm > run-time ABI. > > The issue is with doubles where some of the tested NaN:s only have set > bits in the lower 32 bits of the mantissa. > > From > https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… > --- > > If NaNs are supported, it is only required to recognize, process, and > convert those values with at least one bit set in the 20 most > significant bits of the mantissa. Remaining bits should be zero and > can be ignored. When a quiet NaN of one precision is converted to a > quiet of the other precision, the most significant 20 bits of the > mantissa must be preserved. Consequently: > > * A NaN can be recognized by processing the most significant or only > word of the representation. The least significant word of a double > can be ignored (it should be zero). > * Each ABI-complying value has a single-precision representation, > and a corresponding double-precision representation in which the > least significant word is zero. > * Each ABI-complying NaN value is converted between single- and > double-precision in the same way that Arm VFP VCVT instructions > convert the values. > > --- > > The IAR toolchain only checks the upper 32 bits for NaN / INF and the > double precision NaN tests misinterprets some of the hand crafted > NaN:s as INF. > > How should TF-M handle this? > > 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. > -- *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, 9 months

1
0
0 0

Re: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Tamas Ban

Hi Thomas, An extra logging can be enabled for QCBOR test cases: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/test/suites/qcb… Could you repeat the test with enabled logs, just to know exactly which test cases are failing? The QCBOR library is used for attest token creation, but only a small part of the library which is actually used. The IEEE 754 part of QCBOR is unused in TF-M. So it is not affecting TF-M code, we can temporarily disable those test cases. It is not a blocking issue for IAR support. I put Laurence on cc he is the maintainer of QCBOR library, I think he will be interested in the issue. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 04 February 2020 14:01 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests. I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI. The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa. >From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… --- If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently: * A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero). * Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero. * Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values. --- The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF. How should TF-M handle this? 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, 9 months

1
0
0 0

Persistent keys in the Crypto service

by Jamie Fox

Hi all, I have pushed for review patches to enable persistent keys in the TF-M Crypto service. With these changes, persistent keys will be stored by Mbed Crypto using the ITS APIs exposed by TF-M. The reviews are here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3252 (implementation) https://review.trustedfirmware.org/c/trusted-firmware-m/+/3253 (tests) Currently, merging of these patches is blocked as they depend on Mbed Crypto 2.0 (or greater), which adds support for the latest ITS 1.0.0 APIs exposed by TF-M. Integrating Mbed Crypto 2.0 with TF-M is a work in progress. If anyone wants to test these patches in the meantime, it is possible to cherry pick the patch in the Mbed Crypto repo that adds support for ITS 1.0.0. With the Mbed Crypto repo checked-out at the "mbedcrypto-1.1.0" tag, do a "git cherry-pick bda5a2111" to cherry pick the relevant patch. Kind regards, Jamie

5 years, 9 months

1
0
0 0

HMAC authenticated staic attestation token

by Tamas Ban

Hi, TF-M Profile 1 initiative addressing TF-M footprint reduction to make TF-M usable on more constrained MCUs. As part of this activity attestation service is planned to be refactored as follows: * Static token creation: Not use QCBOR and T_COSE libraries to token creation * HMAC based token authentication: Rely only on symmetric crypto algorithms These changes are optional, the current functionality (dynamic token creation + ECDSA based authentication) remains available and default setting in higher profiles (3). A design proposal was created, feel free to review & comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/3344 BR, Tamas

5 years, 9 months

1
0
0 0

QCBOR, IEEE-754, RFC 7049 and Arm Run-time ABI issues

by Thomas Törnblom

The IAR port of TF-M is mostly done and all regression tests runs OK, with the exception of some of the QCBOR tests. I've analyzed the issue to be the NaN tests to not follow the Arm run-time ABI. The issue is with doubles where some of the tested NaN:s only have set bits in the lower 32 bits of the mantissa. >From https://developer.arm.com/docs/ihi0043/e/run-time-abi-for-the-arm-architect… --- If NaNs are supported, it is only required to recognize, process, and convert those values with at least one bit set in the 20 most significant bits of the mantissa. Remaining bits should be zero and can be ignored. When a quiet NaN of one precision is converted to a quiet of the other precision, the most significant 20 bits of the mantissa must be preserved. Consequently: * A NaN can be recognized by processing the most significant or only word of the representation. The least significant word of a double can be ignored (it should be zero). * Each ABI-complying value has a single-precision representation, and a corresponding double-precision representation in which the least significant word is zero. * Each ABI-complying NaN value is converted between single- and double-precision in the same way that Arm VFP VCVT instructions convert the values. --- The IAR toolchain only checks the upper 32 bits for NaN / INF and the double precision NaN tests misinterprets some of the hand crafted NaN:s as INF. How should TF-M handle this? 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, 9 months

1
0
0 0

TF-M NS regression tests - linker issue

by Reinhard Keil

In CMSIS we are using a Test Framework that offers the flexibility to: 1. output to classic printf, but redirecting is on just a single place. 2. Record test output to memory (for devices that have not printf facility) 3. Output the test results in XML for nice formatting using browsers (we use this for filing test reports). We have used this framework on various projects, across 4 different compilers, on many different targets (simulation, FPGA without UART, etc.). The framework is for example here https://github.com/ARM-software/CMSIS-Driver_Validation/tree/master/Source. But we used it also for various other projects. If there is interest, we could do some work to explain it better and make it scalable to TF-M.

5 years, 9 months

1
0
0 0

Re: [TF-M] Exporting flash_layout.h and region_defs.h

by Anton Komlev

Hi Robert, I see two topics mixing together in this discussion: 1. Project configuration methods/strategy 2. Tooling for that The CMSIS-Zone addresses both of the items somehow. Believe it would be beneficial if you could summaries the thoughts and bring this important topic for discussion on the upcoming Open Technical forum on Feb 6. This would be a good opportunity to present CMSIS-Zone and get a feedback from the community. The best, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 03 February 2020 09:50 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi Robert, “It is a standalone utility that can be used also from command-line. “ The homepage says this is the command to run it “headless”: eclipsec.exe -noSplash -consoleLog –launcher.suppressErrors -application com.arm.cmsis.zone.ui.headlessgen -azone FILENME.azone -ftl FTL_DIR -ftl_gen FTL_GEN_DIR For me this means you still need Eclipse to be installed on your PC to run it and thus this is still and IDE extension just it has support being run headless. There might be ways to run it without Eclipse, but this does not seem to be officially supported. This means there is expected to be sparse information on how-to-do this, no, or limited support. There is a risk in using this tool to generate extra work (need to work out what environment it needs, need to document it, need to test it to ensure proper operation, need to support issues with the environment, etc…). This is not really helping us for now, hopefully this changes in the future. /George From: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>> Sent: 03 February 2020 09:27 To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi Gyorgy, Yes, the memory map needs to be communicated to non-secure world and the existing headers are not the best way. CMSIS-Zone is one possible tool that could help here and make it user friendly. It provides memory partitioning and also assignment of peripherals to secure or non-secure world. It is a standalone utility that can be used also from command-line. Best regards, Robert From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Monday 3 February 2020 09:05 To: Robert Rostohar <Robert.Rostohar(a)arm.com<mailto:Robert.Rostohar@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Exporting flash_layout.h and region_defs.h Hi, Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible. What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue. And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side. There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi, I don’t believe this is the right approach. TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side. While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack. There should be a clean separation of files between the secure and non-secure side. The mentioned header files should not be imposed to the non-secure side. Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately. One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: [TF-M] Exporting flash_layout.h and region_defs.h Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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.

5 years, 9 months

1
0
0 0

Exporting flash_layout.h and region_defs.h

by Reinhard Keil

Hi George The headless mode is functional identical to a command-line mode. I agree that the command line is not self-explaining in the moment, but this can be improved over time. CMSIS-Zone is a tool that is specifically designed for Cortex-M security and MPU configuration. It is fully supported by Arm and part of our CMSIS open source activities. CMSIS-Zone * Supports all Cortex-M23/M33 devices that are on the market public today and extending this support is easy to achieve with an *.rzone file * The *.rzone approach will be part of our IP configuration activities that is under Socrates. * The template engine gives you flexibility for generating many different files, source, header, linker scripts etc. * The tool has both GUI interface and command line mode * All XML files are fully documented and explained * It generates static setup which reduces the run-time overhead and the memory footprint. Both is critical for TF-M * While it requires Eclipse framework, this is not different form other tools (i.e. Phyton requires Phyton framework). So, I somewhat cannot understand your argument. Thanks Reinhard

5 years, 9 months

1
0
0 0

Re: [TF-M] Exporting flash_layout.h and region_defs.h

by Gyorgy Szing

Hi, Looking at the big picture, the secure side is owning the memory map, so it seems to be inevitable to communicate this information to the non-secure world. There are many ways to do this, ranging from capturing the info in documentation to providing configuration to high-level memory layout definition tools. The build system could support multiple options, but the first implementation shall focus on portability. Having a set of header files, which (as the tf-m build system already shows) make the needed information available for both the C program, the linker and the build system, seems to be a good fit to me. It might not be the most user friendly, but is highly accessible. What those header files actually do contain is a different question. Sor security reasons it may be a good idea to remove all information not needed by the NS world. Luckily CMake has the needed features to solve this issue. And when we are at the topic, we need to provide a solution for defining available peripherals to as the secure vs non-secure peripheral availability is also controlled by the secure-side. There seems to be room for a tool independent of tf-m to help standardizing the format this information can be captured in, to help portability of this information and to enhance user-experience. Unfortunately CMSIS-Zone (as per this page https://arm-software.github.io/CMSIS_5/Zone/html/zTInstall.html ) is an IDE extension and thus it is hardly applicable in a command-line focused build environment. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 03 February 2020 08:15 To: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] Exporting flash_layout.h and region_defs.h Hi, I don’t believe this is the right approach. TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side. While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack. There should be a clean separation of files between the secure and non-secure side. The mentioned header files should not be imposed to the non-secure side. Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately. One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> Subject: [TF-M] Exporting flash_layout.h and region_defs.h Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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.

5 years, 9 months

2
2
0 0

Re: [TF-M] Exporting flash_layout.h and region_defs.h

by Robert Rostohar

Hi, I don’t believe this is the right approach. TF-M currently includes a non-secure side application (integration test) which is built together with the secure side. This is also reflected in “flash_layout.h” and “region_defs.h” which mixes defines for the secure and non-secure side. While this might be convenient within TF-M current build setup for the platforms that are supported, it causes issues in real applications and when trying to make this scalable across a large number of platforms. We have seen those issues already while working on providing TF-M as a CMSIS-Pack. There should be a clean separation of files between the secure and non-secure side. The mentioned header files should not be imposed to the non-secure side. Typically non-secure software will have a device specific linker script which will only need to know limited information from the memory layout (non-secure code and data location). Also the secure side might be prebuilt and the non-secure side developed and built separately. One possible solution is to use a CMSIS-Zone to partition the memory layout on a global level and then splitting it to sub-systems for secure and non-secure and exporting only relevant information for each side. This approach will be used also with TF-M CMSIS-Pack which should be available soon. Best regards, Robert From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday 31 January 2020 17:09 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] Exporting flash_layout.h and region_defs.h Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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.

5 years, 9 months

1
0
0 0

Re: [TF-M] TF-M NS regression tests - linker issue

by Ken Liu

Hi, Why the title is ‘linker issue’ since it is discussing about the printf things? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Devaraj Ranganna via TF-M Sent: Friday, January 31, 2020 9:57 PM To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TF-M NS regression tests - linker issue Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks Thanks, Dev 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, 9 months

1
0
0 0

Re: [TF-M] Compilation failure

by Jamie Fox

Hi Chris, Approved and merged, based on the two +1 reviews. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: 31 January 2020 17:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Compilation failure https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? Thanks, Chris 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, 9 months

2
1
0 0

Compilation failure

by Christopher Brand

https://review.trustedfirmware.org/c/trusted-firmware-m/+/3243 fixes a compilation error for the armclang build of the PSoc64 platform. The error was introduced by commit e3c75a4955e665e78d55b22f07db73d31a6bf101 (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3031/10 ) which was merged 21st January. It would be really nice to have this breakage last less than two weeks, so is there somebody around who can approve it? Thanks, Chris 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, 9 months

1
0
0 0

Exporting flash_layout.h and region_defs.h

by Devaraj Ranganna

Hi, The headers `flash_layout.h` and `region_defs.h` as the name suggests defines layout of flash and how different regions are organised in flash and ram respectively. These headers define the location of Bootloader if any, secure and non-secure firmware in flash and these defines are used in the linker scripts. As far as I can tell, these headers will be used by NS RTOS without any modifications, I can confirm that, this is the case in Mbed OS. Since these headers are usually imported into NS RTOS without any modifications, I propose that we export these headers as part of the build. Thanks, Dev 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, 9 months

1
0
0 0

TF-M NS regression tests - linker issue

by Devaraj Ranganna

Hi, The TF-M NS regression tests were portable enough to run in a rich OS environment. After replacing printf with tfm_log_printf, the TF-M regression tests are now no longer portable enough to run in an OS environment. Many OSes already have a way to print, usually via a printf function, and the TF-M regression tests probably should use this. It's important that TF-M regression tests remain portable and capable of running in an OS environment so that system integrators can be confident that TF-M is working as intended post-integration. I’ve already created a ticket for this https://developer.trustedfirmware.org/T664 Response from Ken in the ticket: Hi Jamie, The background for this changing is, the ARMCLANG printf involves \_\_stdout' into the image and this conflicts with some CMSIS functionalities. (CMSIS team reported that __stdout would affect the mutex init in ARMCLANG). That is the reason why I skipped the default printf. I think for an RTOS, the toolchain provided printf sometimes come with unknown symbols and causes unexpected behaviour, as the discussion in list/channel, most people are trying to avoid toolchain printf and use some lightweight output. And for the test, it should use wrapped TEST_LOG(), instead of calling printf itself, since some RTOS do not provide a std 'printf' function. Is there any discussion thread about this issue? Thanks Thanks, Dev 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, 9 months

1
0
0 0

TF-M Technical Forum call - February 6

by Anton Komlev

Dear All, The next Technical Forum is planned on Thursday, February 6 at 7:00-8:00 UTC. Please reply on this email with your proposals for agenda topics. Any questions, proposals, concerns are all valid points for our open discussion so do not hesitate to share it. A big or complicated topics are worth to preliminary discussion over the mailing list. Best regards, Anton Komlev

5 years, 9 months

1
1
0 0

AN521 debugging

by Thomas Törnblom

As the IAR ports for Musca A and psoc64 are more or less complete, I've started looking at the MPS2/MPS3 targets. After some initial issues I can now connect our debugger via USB using CMSIS-DAP. However I'm not getting and serial ports configured on my Win10 laptop when connecting to an MPS2+ board running the AN521 (M33) image. Shouldn't that show up automatically like it does with the MPS3? Or do I need to use the physical serial port on the board? I would appreciate reviews of the IAR port as well, see https://review.trustedfirmware.org/c/trusted-firmware-m/+/3295 Thanks, 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, 9 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M