Hi,
The agenda for the forum tomorrow:
1. "Summary of the proposed changes in FF-M v1.1 beta" by Andrew Thoelke
2. "Summary of upcoming significant changes in SPM" by Ken Liu
containing:
* MMIO and interrupt binding.
* Remove unformal symbols such as ARM_LIB_STACK_MSP.
Thanks,
Anton
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Saturday, August 28, 2021 9:36 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - Sep 2
Hi,
There are some significant changes happen in SPM and I want to introduce them in a summary, contains:
* MMIO and interrupt binding.
* Remove unformal symbols such as ARM_LIB_STACK_MSP.
Assuming 30 mins should be good enough.
BR
/Ken
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: Wednesday, August 25, 2021 7: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] Technical Forum call - Sep 2
Hi,
The next Technical Forum is planned on Thursday, September 2, 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi all,
We plan to merge the below patch on next Monday.
We will not be able to verify on all platforms.
Please do have a test on your platforms.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, August 24, 2021 11:02 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Changing initialization Stack from PSP to MSP
Hi dear platform maintainers,
I'd like to draw your attention on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11165>.
It changes the initialization stack from PSP to MSP.
Would you please check if this change breaks your platform?
Hi Thomas@IAR, would you please check the changes for IAR?
Thanks.
For the details of the change, please refer to the patch.
Best Regards,
Kevin
The patchset has updated and now CI passed okay:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11187
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 19, 2021 2:16 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [Request Platform Support] Abstracted MMIO HAL
Hi everyone,
The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries.
Hence, a deeper abstracted interface are provided. Here are the details:
- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.
- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).
- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.
- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.
- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.
We created a patch to showcase the usage on AN521:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.
Now come to the request:
Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.
Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.
Any feedbacks are welcome.
Thank you very much!
/Ken
Hi,
There are some significant changes happen in SPM and I want to introduce them in a summary, contains:
* MMIO and interrupt binding.
* Remove unformal symbols such as ARM_LIB_STACK_MSP.
Assuming 30 mins should be good enough.
BR
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, August 25, 2021 7:13 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - Sep 2
Hi,
The next Technical Forum is planned on Thursday, September 2, 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Chris,
It is an excellent suggestion.
Out-of-tree Secure Partition build can help integrate secure test service.
Non-secure tests are a bit limited due to current tf-m-tests framework right now.
Do you prefer to run platform-specific tests alone or still integrate platform-specific tests into TF-M regression tests?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of chris.brand--- via TF-M
Sent: Tuesday, August 24, 2021 11:46 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Just wondering if any though has been given to supporting platform-specific tests?
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, August 24, 2021 3:21 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi Andrej,
Thanks for the suggestion. Sure. I will track it in the backlog.
Currently Jianliang and I are more focusing on the structure level enhancement. But definitely later we will take more effort in the detailed optimizations.
Please let us know any time if any other potential issue shall be optimized.
Best regards,
Hu Ziji
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Tuesday, August 24, 2021 6:15 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Hu Zij,
Thank you for adding possibility to select test cases flexibly.
Also, there are about 10 "test" services/partitions in addition to the core PSA ones.
But every instance allocates own resources, which can be shared.
Guess, merging these 10 test services, which have a common structure, can save some memory.
Thank you,
Andrej
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Tuesday, August 24, 2021 11:54 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Andrej,
Sorry for the trouble.
It does be an issue when TF-M features and test cases are growing faster.
So now TF-M support to select a single test case or a subset of test cases to build and run. If running all the tests together costs too much memory, you can select some test cases or just a single one in one time.
It is also helpful when you focus on a specific test in debug or development.
We are also considering other additional mechanisms to select test case flexibly.
Regarding "merging existing ones", do you mean that some test cases shall be disabled by default or combining the similar test cases? May I ask for some examples?
Best regards,
Hu Ziji
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Tuesday, August 24, 2021 5:44 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Hu Ziji,
BTW:
The number of the testing partitions and services is growing consuming memory resources.
So, we have to disable some tests for our memory constrained devices.
Please think about minimizing number of "testing" partitions/services, by merging existing ones, when it is possible.
Thank you,
Andrej Butok
SW Tech Lead
Edge Processing
NXP Semiconductors
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, August 24, 2021 11:33 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: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Hi all,
As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo.
The purpose of the decoupling enhancement includes:
* Making it more easier to integrate TF-M and port tf-m-tests
* Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system.
* Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M
Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test.
Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M.
So far we have proposed the following major changes:
* Decouple tf-m-tests specific config setting from trusted-firmware-m.
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
* Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
More patch sets for decoupling are under review as well.
* Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log.
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
* Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome.
If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me.
Thanks in advance.
Best regards,
Hu Ziji
Hi,
The next Technical Forum is planned on Thursday, September 2, 15:00-16:00 UTC (US time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Just wondering if any though has been given to supporting platform-specific tests?
Chris
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: Tuesday, August 24, 2021 3:21 AM
To: Andrej Butok <andrey.butok(a)nxp.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informati…>.
Hi Andrej,
Thanks for the suggestion. Sure. I will track it in the backlog.
Currently Jianliang and I are more focusing on the structure level enhancement. But definitely later we will take more effort in the detailed optimizations.
Please let us know any time if any other potential issue shall be optimized.
Best regards,
Hu Ziji
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Tuesday, August 24, 2021 6:15 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Hu Zij,
Thank you for adding possibility to select test cases flexibly.
Also, there are about 10 "test" services/partitions in addition to the core PSA ones.
But every instance allocates own resources, which can be shared.
Guess, merging these 10 test services, which have a common structure, can save some memory.
Thank you,
Andrej
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Tuesday, August 24, 2021 11:54 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Andrej,
Sorry for the trouble.
It does be an issue when TF-M features and test cases are growing faster.
So now TF-M support to select a single test case or a subset of test cases to build and run. If running all the tests together costs too much memory, you can select some test cases or just a single one in one time.
It is also helpful when you focus on a specific test in debug or development.
We are also considering other additional mechanisms to select test case flexibly.
Regarding "merging existing ones", do you mean that some test cases shall be disabled by default or combining the similar test cases? May I ask for some examples?
Best regards,
Hu Ziji
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Tuesday, August 24, 2021 5:44 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [RFC] Decoupling tf-m-tests from TF-M
Hi Hu Ziji,
BTW:
The number of the testing partitions and services is growing consuming memory resources.
So, we have to disable some tests for our memory constrained devices.
Please think about minimizing number of "testing" partitions/services, by merging existing ones, when it is possible.
Thank you,
Andrej Butok
SW Tech Lead
Edge Processing
NXP Semiconductors
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, August 24, 2021 11:33 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: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Hi all,
As you may know, Jianliang and I are working to better decouple tf-m-tests from trusted-firmware-m repo.
The purpose of the decoupling enhancement includes:
* Making it more easier to integrate TF-M and port tf-m-tests
* Making it more easier to develop TF-M tests, to minimize the changes to TF-M source code or build system.
* Making it more flexible to re-structure tf-m-tests and minimize the impact to TF-M
Previously Jianliang has decouple test case control and enable users to select single NS/S regression test case in build and test.
Currently we are focusing on decoupling tf-m-tests specific config setting from TF-M.
So far we have proposed the following major changes:
* Decouple tf-m-tests specific config setting from trusted-firmware-m.
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
* Move tf-m-tests specific configs to tf-m-tests repo from trusted-firmware-m
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
More patch sets for decoupling are under review as well.
* Decouple tf-m-tests secure log from non-secure log. Switch tf-m-tests secure log to TF-M SP log.
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
* Trigger secure regression tests in TF-M SPE in IPC model, to simplify multi-core development/tests
[TF-M patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>][tf-m-tests patch<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>]
I'd appreciate it if you can take a look at the patch sets above. Any suggestion or comment is welcome.
If you have any specific requirement or suggestion of tf-m-tests enhancement, please feel free to contact Jianliang and me.
Thanks in advance.
Best regards,
Hu Ziji
Hi Hu Ziji,
BTW:
The number of the testing partitions and services is growing consuming
memory resources.
So, we have to disable some tests for our memory constrained devices.
Please think about minimizing number of "testing" partitions/services, by
merging existing ones, when it is possible.
Thank you,
Andrej Butok
SW Tech Lead
Edge Processing
NXP Semiconductors
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu
via TF-M
Sent: Tuesday, August 24, 2021 11:33 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] [RFC] Decoupling tf-m-tests from TF-M
Hi all,
As you may know, Jianliang and I are working to better decouple tf-m-tests
from trusted-firmware-m repo.
The purpose of the decoupling enhancement includes:
* Making it more easier to integrate TF-M and port tf-m-tests
* Making it more easier to develop TF-M tests, to minimize the changes
to TF-M source code or build system.
* Making it more flexible to re-structure tf-m-tests and minimize the
impact to TF-M
Previously Jianliang has decouple test case control and enable users to
select single NS/S regression test case in build and test.
Currently we are focusing on decoupling tf-m-tests specific config setting
from TF-M.
So far we have proposed the following major changes:
* Decouple tf-m-tests specific config setting from trusted-firmware-m.
[TF-M patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11167&data=04%7C01
%7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C637653943958809255%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata
=4nA45CyrLoYjN2b9ytZ6HL16Of9ItUs5OAUbPlsFPTM%3D&reserved=0> ][tf-m-tests
patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11169%2F1&data=04%7C01%7Ca
ndrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa
92cd99c5c301635%7C0%7C0%7C637653943958809255%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aBB
0Wq8QLghyfAdwzpK%2BHR8R8LVN5emXxL0KOc4bPho%3D&reserved=0> ]
* Move tf-m-tests specific configs to tf-m-tests repo from
trusted-firmware-m
[TF-M patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F10647&data=04%7C01
%7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C637653943958819210%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata
=QwtROeuQVK8nWtprtRVZJnzXM2%2FBgX1ZZspl6dsxBFE%3D&reserved=0> ][tf-m-tests
patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F10556&data=04%7C01%7Candre
y.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa92cd
99c5c301635%7C0%7C0%7C637653943958819210%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IYzd75F
NoPwLLzoHqvpNJrn4fAaHTeOYzTujFWJDPTQ%3D&reserved=0> ]
More patch sets for decoupling are under review as well.
* Decouple tf-m-tests secure log from non-secure log. Switch
tf-m-tests secure log to TF-M SP log.
[TF-M patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11153&data=04%7C01
%7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C637653943958829167%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata
=27x4o2UrAFCFMFx3fC7ebiv0EAsBvOEtY%2BqtZzc7Q6Q%3D&reserved=0> ][tf-m-tests
patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11131%2F3&data=04%7C01%7Ca
ndrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa
92cd99c5c301635%7C0%7C0%7C637653943958829167%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xT5
oks2R0hXyCorWsfkytx%2FCidUF8%2Bv6jMBAFxrgf2g%3D&reserved=0> ]
* Trigger secure regression tests in TF-M SPE in IPC model, to
simplify multi-core development/tests
[TF-M patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftrusted-firmware-m%2F%2B%2F11181&data=04%7C01
%7Candrey.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4
c6fa92cd99c5c301635%7C0%7C0%7C637653943958839123%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata
=tMKKb6FHOh1pBZg62QKHBUCXaAXmv8o%2F%2Bwabe2XXOnc%3D&reserved=0> ][tf-m-tests
patch
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr
ustedfirmware.org%2Fc%2FTF-M%2Ftf-m-tests%2F%2B%2F11182&data=04%7C01%7Candre
y.butok%40nxp.com%7Ce6deb39c9db74755362008d966e231b0%7C686ea1d3bc2b4c6fa92cd
99c5c301635%7C0%7C0%7C637653943958839123%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j6Hf2wa
6wKm8LphtLfo8SK8kkhnazAJ%2F5RrN2eUhFIc%3D&reserved=0> ]
I'd appreciate it if you can take a look at the patch sets above. Any
suggestion or comment is welcome.
If you have any specific requirement or suggestion of tf-m-tests
enhancement, please feel free to contact Jianliang and me.
Thanks in advance.
Best regards,
Hu Ziji
Hi dear platform maintainers,
I'd like to draw your attention on this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11165>.
It changes the initialization stack from PSP to MSP.
Would you please check if this change breaks your platform?
Hi Thomas@IAR, would you please check the changes for IAR?
Thanks.
For the details of the change, please refer to the patch.
Best Regards,
Kevin
Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device.
* MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware.
* MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot).
* MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot)
* When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash
* Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task
* However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things.
* In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side
* Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image
* Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application
|
| Function call
V
FWU API
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot Shim Layer
|
| Function call
V
MCUBoot user API
========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot
|
|
V Function call, never returns
Reset_Handler of new image
BR,
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M
Sent: 2021. május 25., kedd 16:16
To: Andrew Thoelke <Andrew.Thoelke(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application
|
| Function call
V V
MCUBoot user API |
Shim layer |
| |
| Function call |
V |
FWU API <------------|
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot user API
MCUBoot engine
MCUBoot image size is around 60K and
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke(a)arm.com<mailto:Andrew.Thoelke@arm.com>>
Sent: Tuesday, May 25, 2021 1:39 AM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
> I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
Are you suggesting that the software stack might look like this:
Update client application
|
| Function call
V
MCUBoot user API
Shim layer
|
| Function call
V
FWU API
|
| TF-M psa_call() etc.
V
FWU Partition
|
| Function call
V
MCUBoot user API
MCUBoot engine
This looks like it has one more layer than it needs, as either:
1. The Update client application could Talk directly to the FWU API, or
2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose.
Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition?
Regards,
Andrew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: 25 May 2021 02:37
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@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] Firmware update API - MCUboot update
Hi Sherry,
Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API.
Details that would help:
1. How the MCUboot works without the FWU API - natively
2. How the MCUBoot needs to be modified to leverage from FWU API
3. What components are retained in MCUBoot ex: image format, signing, metadata, tools
I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition.
The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Thursday, May 13, 2021 7:51 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>.
We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>.
Can you please provide more specific suggestion or questions?
Regards,
Sherry Zhang
From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>
Sent: Thursday, May 13, 2021 11:40 PM
To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@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: Firmware update API - MCUboot update
Hi Sherry,
Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>
Sent: Wednesday, May 12, 2021 8:55 PM
To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.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: Firmware update API - MCUboot update
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>.
Hi Suresh,
The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on.
The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely.
I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process.
The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M
Sent: Thursday, May 13, 2021 11:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Firmware update API - MCUboot update
Hi,
I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot.
Does the use of this API make the MCUboot update services redundant?
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Lead Member of Technical Staff
CYSC CSS ICW SW SSE
Mobile: +5103863997
Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>
Hi all,
Out-of-tree secure partition build is enabled in TF-M.
I'd appreciate it if you are interested to try it in your daily development. Any feedback 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: Thursday, August 12, 2021 11:54 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Out-of-tree secure partition build support
Hi all,
Can I ask you to review the following patch set to enable out-of-tree secure partition build in TF-M?
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10562/
The purpose is to enable developers to develop their own secure partitions outside TF-M repo. Developers can maintain their own code and repos, independently.
Developers can pass their out-of-tree secure partition paths via TF-M command line, to build out-of-tree partitions with TF-M together.
For more details, please check the updated document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10696
Suggestions and comments are welcome!
Best regards,
Hu Ziji
Hi all.
I have introduced the topic of test configurations refinements in the tech forum on August 5. With this new feature, you can build single test case to decrease the image size and the time to wait irrelevant test cases running when debugging. You can use all the 22 new flags in test repo:
TEST_NS
TEST_S
TEST_NS_ATTESTATION
TEST_NS_AUDIT
TEST_NS_CRYPTO
TEST_NS_ITS
TEST_NS_PS
TEST_NS_PLATFORM
TEST_NS_FWU
TEST_NS_IPC
TEST_NS_CORE
TEST_NS_QCBOR
TEST_NS_T_COSE
TEST_NS_MULTI_CORE
TEST_NS_SLIH_IRQ
TEST_NS_FLIH_IRQ
TEST_S_ATTESTATION
TEST_S_AUDIT
TEST_S_CRYPTO
TEST_S_ITS
TEST_S_PS
TEST_S_PLATFORM
TEST_S_FWU
TEST_S_IPC
You can easily use the command below to start single test like NS attestation test case:
cmake -S . -B cmake_build -DTFM_PLATFORM=arm/mps2/an521 \
-DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake \
-DCMAKE_BUILD_TYPE=Release \
-DTFM_PSA_API=ON \
-DTEST_NS_ATTESTATION=ON
Meanwhile, you may receive the warning messages when your test inputs are not supported on the platform.
Here are the patches about this change, any suggestions or improvements are welcome in code review.
l 10767: Build: Control single test without TEST_S/TEST_NS [TF-M repo] https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10767
l 10768: Build: Control single test without TEST_S/TEST_NS [Test repo] | https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10768
Best Regards
Jianliang Shen
Hi Anton,
Did you missed my topic below - brief update on the interrupt status in TF-M and an introduction on how to use/enable it
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Wednesday, August 18, 2021 11:13 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - Aug 19
The agenda for the forum:
1. "Of out-of-tree Secure Partition build" by David Hu,
2. AOB
See you,
Anton
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 18, 2021 2:30 AM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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: Technical Forum call - Aug 19
Hi Anton,
I'd like to introduce the proposal of out-of-tree Secure Partition build.
It may take 15 ~ 20 mins.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, August 17, 2021 5:49 PM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Technical Forum call - Aug 19
Hi Anton,
I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it.
Would take ~20 min.
Best Regards,
Kevin
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: Tuesday, August 17, 2021 5:26 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] Technical Forum call - Aug 19
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi everyone,
The existing HAL interface for isolation hardware is not unified, we have to call several interfaces to setup isolation boundaries.
Hence, a deeper abstracted interface are provided. Here are the details:
- It assumes the hardware resources usages are decided by system designer. Hence there are couple of listed hardware data in the platform code, now most of them are defined in C sources.
- When a partition is referencing peripheral (represented as MMIO in FFM), the manifest tooling would link specified resources with the data defined in platform. Now it is using a naming pattern, to let the partition found the resources defined above (now it uses linker to do this).
- A HAL API 'tfm_hal_bind_partition' is called when a partition runtime structure is created. This API tells partition info to platform, let platform return an encoded 'p_boundaries' for SPM binding partition with platform.
- When boundaries related operations happen in future, SPM would delivery this 'p_boundaries' back to platform, let platform perform boundary setup and check, such as boundary switch or memory check. SPM won't care about the hardware specific settings any more, such as privilged, non-secure/secure and how many MMIO the partition claimed, even the MPU/MPC/PPC things.
- Resources defined in platform sources but not referenced would be stripped by toolchain flag. Resources not defined but referenced by partition would generate a linker error, as symbol can't be resolved.
We created a patch to showcase the usage on AN521:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
This patch applies a simple encoding for all isolation levels. You can check how the p_boundaries is used under different isolation levels. Platform can use other encoding mechanism if applicable.
Now come to the request:
Please review this patch, and port similar HAL API into your platform. We are maintaining the default platforms such as AN521, AN519 and MUSCA_B1, but it need so much effort on port to all the platforms.
Current CI cannot pass on this patch (as it contains modification for one platform only), our first goal is to let CI pass build on all checked platforms, and then please platform owner ensures it works on your platform.
Any feedbacks are welcome.
Thank you very much!
/Ken
Hi Anton,
I'd like to introduce the proposal of out-of-tree Secure Partition build.
It may take 15 ~ 20 mins.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M
Sent: Tuesday, August 17, 2021 5:49 PM
To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Technical Forum call - Aug 19
Hi Anton,
I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it.
Would take ~20 min.
Best Regards,
Kevin
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: Tuesday, August 17, 2021 5:26 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] Technical Forum call - Aug 19
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Anton,
I'd like to give a brief update on the interrupt status in TF-M and an introduction on how to use/enable it.
Would take ~20 min.
Best Regards,
Kevin
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Tuesday, August 17, 2021 5:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - Aug 19
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi,
The next Technical Forum is planned on Thursday, Aug 19 at 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi Ken,
“double-check every return value of sub-functions, this is really a burden when under developing”
That’s exactly why FIH can help mitigate physical attacks. It adds redundant checks and increases the complexity in code to make it difficult for attackers.
It of course also increase develop efforts and it is expected for physical attack mitigation.
Regarding tight schedule, it can be workaround by splitting the HAL API definitions with and without FIH enabled respectively.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:54 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Thanks, then we can do some planning and make the FIH feature online again before the deadline.
I do agree FIH needs an update. There would be reasons for HAL to change its implementation or prototype; and the existing FIH needs another copy of implementation, change the prototype a bit, and double-check every return value of sub-functions, this is really a burden when under developing: We first need to ensure the non-FIH version work, get reviewed; and then prepare the FIH version, get reviewed again. And, the platform owner may be afraid of changing the HAL implementation, as it is risky to do that.
I’d suggest enhancing the solution that:
- Doing measurement without changing HAL API prototype.
As the bandwidth is always a problem, so I have to prioritize the designs. Let’s see if we can get help from people. Otherwise, I will allocate some effort after HAL update is done. This means, there would be a couple of HAL updates with no FIH support recently, and FIH version comes later.
Any volunteer is welcome.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:39 PM
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Next platform with FIH enabled is foreseen to be in V1.5.0 with FIH enabled (the pull request without FIH enabled is expected in september)
FIH support is planned on later pull request.
So FIH recovering needs to be done at least 3 weeks before V1.5.0 code freeze, to let the time to do adaptation/test /fix on this new platform.
Best Regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: jeudi 12 août 2021 10:34
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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] [Question] FIH usage in platforms
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
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: Thursday, August 12, 2021 4:26 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] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
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: mercredi 11 août 2021 07:24
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] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when “recovering back”: if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome – that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won’t weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are “recovered back”.
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
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: Monday, August 9, 2021 10:18 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: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hello,
Next platform with FIH enabled is foreseen to be in V1.5.0 with FIH enabled (the pull request without FIH enabled is expected in september)
FIH support is planned on later pull request.
So FIH recovering needs to be done at least 3 weeks before V1.5.0 code freeze, to let the time to do adaptation/test /fix on this new platform.
Best Regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M
Sent: jeudi 12 août 2021 10:34
To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
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: Thursday, August 12, 2021 4:26 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] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
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: mercredi 11 août 2021 07:24
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] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
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: Monday, August 9, 2021 10:18 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: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hi Ken,
Imho, it can be more reasonable to improve HAL and FIH API together, compared to removing existing security protection.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Thursday, August 12, 2021 4:26 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi Michel,
Is there a rough timeline for the next stm platform? I can estimate if we got time to update or add it back.
Besides that, curious if ST got test environments for FIH? If there are some then at least we have a method to evaluate the FIH effect.
BR.
/Ken
From: Michel JAOUEN <michel.jaouen(a)st.com<mailto:michel.jaouen@st.com>>
Sent: Thursday, August 12, 2021 4:21 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: [Question] FIH usage in platforms
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
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: mercredi 11 août 2021 07:24
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] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
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: Monday, August 9, 2021 10:18 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: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hello,
Regarding FIH feature, for stm next platform I consider FIH as key for Faul injection Mitigation, so the FIH is enabled for the next stm platform.
Even if a platform gets certified without this FIH feature, other mitigations at platform level have been set to get certified.
The benefits of FIH is to make the mitigation available for all platform, so I consider that maintaining it during development is important.
Best regards
Michel
ST Restricted
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: mercredi 11 août 2021 07:24
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Question] FIH usage in platforms
Hi David,
This mail is seeking evidence about how FIH is effectively working. As the latest L3 certified device is still using v1.0-RC2, where the FIH is not supported in that codebase.
I assumed a pre-condition when "recovering back": if FIH still can prove its importance. The FIH has to be enhanced before recovering back. FIH is a serious hardware feature so what software can do is limited. Delay and Double-check protection unit is the two easiest way can be applied. Other behaviors, as we can see, affect the development much, which makes it more proper to be done in toolchain instead of programming.
Compare with this complex but less used mechanism, we have prioritized features to be done. That is the reason why we need to do the feature development first instead of solving the development difficulty at the current stage.
Meanwhile, anyone proposing a better FIH mechanism is welcome - that would make the feature development and difficulty solving in parallel.
BR.
/Ken
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: Wednesday, August 11, 2021 11:53 AM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@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: [Question] FIH usage in platforms
Hi Ken,
Based on your idea, several fundamental countermeasures against physical attacks will be removed.
* Double checking return value
* Execution flow counters
* Structured variables with initial failure values
Mitigation to physical attacks is required in PSA Level 3 certify. It is crucial for TF-M to provide reasonable physical attack mitigations.
Please provide proper justifications to prove that removal of those countermeasures above won't weaken existing protection against physical attacks.
On the other hand, even if those countermeasures above are removed now, it will still affect the HAL updates when they are "recovered back".
So why not solve the development difficulty at this moment?
Best regards,
Hu Ziji
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: Monday, August 9, 2021 10:18 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: [TF-M] [Question] FIH usage in platforms
Hi,
Is there anyone enables FIH when developing or releasing?
Background:
We got a couple of HAL updates during feature development and found FIH affects the development progress much, as we need to provide two sets of prototypes and implementation for involved functions, this doubles the efforts on debugging or coding.
So a draft idea in my mind is to shut down part of the functionalities during this update stage and recover them back if FIH still can prove its importance later.
These functionalities are KEPT during the update stage:
- FIH delay, which makes it harder to find the exact time point.
- Protection unit validation, ensures the protection unit is initialized as expected.
Please provide your feedback about the usage and the idea. For platforms that are applying this feature, we need to find out a trade-off way.
Thanks.
/Ken
Hi all,
Can I ask you to review the following patch set to enable out-of-tree secure partition build in TF-M?
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10562/
The purpose is to enable developers to develop their own secure partitions outside TF-M repo. Developers can maintain their own code and repos, independently.
Developers can pass their out-of-tree secure partition paths via TF-M command line, to build out-of-tree partitions with TF-M together.
For more details, please check the updated document: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10696
Suggestions and comments are welcome!
Best regards,
Hu Ziji
Hi,
A platform binding HAL API "tfm_hal_bind_partition()" is being introduced to TF-M.
This API lets the platform records partition information, and applies specific settings. An encoded handle is returned to SPM, so that SPM can use the handle to decide when and how to update isolation boundaries. The "tfm_hal_update_boundaries()" API is updated accordingly.
Check details in the patch.
Implementation on AN521 is here:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/11036
Any feedback and comments are welcome :)
Thanks,
MIngyang
Hi Jamie,
10-2020-q4-major is the latest release version. I have no idea on when the defect can be fixed in the future GCC 10 release. I think you can query that information in the tools community
https://community.arm.com/developer/tools-software/tools?_ga=2.153861944.16….
Regards,
Sherry Zhang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 5:50 PM
To: David Hu <David.Hu(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] TF-M v1.4.0 release started
Hi David,
The ARM GCC 10 build from https://developer.arm.com/tools-and-software/open-source-software/developer… does indeed seem to be the cause of the issue, tests are now all passing. Do you know on any timeframe for when an updated version of GCC 10 will be available from ARM which fixes this issue?
Thanks,
Jamie
From: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>
Sent: 27 July 2021 10:09
To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>>; Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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 v1.4.0 release started
Hi Jamie,
Can I ask about your toolchain in use?
GNUARM 10-2020-q4-major will cause a similar issue. TF-M suggests to avoid using this version: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/getti….
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M
Sent: Tuesday, July 27, 2021 4:48 PM
To: Jamie Mccrae <Jamie.Mccrae(a)lairdconnect.com<mailto:Jamie.Mccrae@lairdconnect.com>>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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: [TF-M] FW: TF-M v1.4.0 release started
Hi Jamie,
Sorry for the trouble.
According to your description, the violation error is caused by non-secure test cases. is it correct?
The error message is dumped by tfm_secure_api_error_handler(). It is called multiple times in Library model routine.
Can you please help narrow the step in which tfm_secure_api_error_handler() is called?
Besides, do you mind trying if IPC model can work on your board?
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Jamie Mccrae via TF-M
Sent: Tuesday, July 27, 2021 3:43 PM
To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] TF-M v1.4.0 release started
Hi,
I have tried the RC1 and RC2 on our platform, the BL5340 (nRF5340-based), which I am testing by building with the following:
cmake -DTFM_PLATFORM=lairdconnectivity/bl5340_dvk_cpuapp -GNinja -DTFM_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DTEST_S=on -DTEST_NS=on -DCMAKE_BUILD_TYPE=debug -DPS_TEST_NV_COUNTERS=on ..
And upon starting the non-secure tests, a security violation occurs which reboots the module. Output from secure core:
Test suite 'Crypto secure interface tests (TFM_S_CRYPTO_TEST_1XXX)' has PASSED
Test suite 'Initial Attestation Service secure interface tests(TFM_S_ATTEST_TEST_1XXX)' has PASSED
Test suite 'Platform Service Secure interface tests(TFM_S_PLATFORM_TEST_1XXX)' has PASSED
Test suite 'Audit Logging secure interface test (TFM_S_AUDIT_TEST_1XXX)' has PASSED
*** End of Secure test suites ***
Security violation when calling secure API
[INF] Starting bootloader
[INF] Primary image: magic=good, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[INF] Boot source: primary slot
Output from non-secure core:
Non-Secure system starting...
#### Execute test suites for the Non-secure area ####
Running Test Suite PSA protected storage NS interface tests (TFM_NS_PS_TEST_1XXX)...
> Executing 'TFM_NS_PS_TEST_1001'
Description: 'Set interface'
Non-Secure system starting...
So something that has changed from 1.3 to 1.4 seems to have broken our platform.
Thanks,
Jamie
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: 26 July 2021 09:50
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] TF-M v1.4.0 release started
EXTERNAL EMAIL: Be careful with attachments and links.
Hi,
All TF-M repositories are updated with TF-Mv1.4.0-RC2 tag.
The changes are minimal and shall not invalidate the tests, already done.
Please use this tag for new tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
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: Wednesday, July 21, 2021 11:25 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: [TF-M] TF-M v1.4.0 release started
Hi,
All TF-M repositories are tagged with TF-Mv1.4.0-RC1 tag.
Code is frozen now for the release candidate testing. Note that changes to other repositories are still possible during that time.
Please use this tag for your tests and report any issues found by the end of July 30.
Thanks and good luck,
Anton
THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.
