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
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
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
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
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.
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
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
Hello everyone, I'm new to the list. Quick introduction: I work at Texas Instruments and I'm investigating TFM for use in some of our platforms here.
I'm trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks.
I found the following:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone_…
The existing TFM implementation doesn't seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don't see where it uses that information to do anything.
Am I missing something?
I'd like to understand more about where TFM is going with the tz_context interface.
Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS client is "active." But it isn't clear to me if this is the direction or not.
I note that the text for TZ_LoadContext_S says "**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules." Preparing sounds different than immediate execution.
Are there other documents I can read or source implementations I can reference to get more of a handle on this?
Thanks,
Erik Shreve, PSEM
Software Security Engineer & Architect (CMCU Platform Development)
Texas Instruments
Hello,
The next Technical Forum is planned on Thursday, March 19 at 7:00-8:00 UTC.
Please reply on this email with your proposals for agenda topics.
Best regards,
Anton Komlev
Hi,
TF-M version information is carried by manifest data, which is appended to the image in a post build step (at image signing):
* Image header: Contains image actual version: 1.0.0
* Image TLV (footer): Can contains a dependency TLV entry which refers to the dependent image by an ID and its minimum version.
Dependency verification:
* At boot time the bootloader checks whether the dependency would be satisfies after a software upgrade. If not then it deny the update.
* https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guide…
At runtime there is no API to get the image version or its capability.
Did I answer your question?
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M
Sent: 09 March 2020 09:45
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Product Lifecycle Management: TF-M + Non-Secure Application
Hi,
How does TF-M consider Product Lifecycle Management (PLM)?
Assuming the following scenario where TF-M and Non-Secure Application are independently developed/updated in a deployed system:
* TF-M is delivered i.e. by a silicon vendor in a pre-configured variant and Non-Secure Application starts to use this configuration.
* During PLM there is a decision to update/upgrade/downgrade TF-M. The new image is pushed to deployed devices independent of Non_Secure application.
Questions that I have:
* Is there a way for the Non-Secure application to identify the functionality available in TF-M?
* How is it ensured that new TF-M versions are compatible with previous versions?
Reinhard
