Hi Anton,
I would like to discuss the linker script integration things, would summarized the situation and potential improvement plan.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M
Sent: Friday, May 7, 2021 2:20 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Technical Forum call - May 13
Hi,
The next Technical Forum is planned on Thursday, May 13, 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,
The next Technical Forum is planned on Thursday, May 13, 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 Jamie,
The patch has been reviewed and merged.
Thanks.
Regards,
David Wang
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: Thursday, May 6, 2021 2:48 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi,
Would it be possible to get some quick reviews on some fixes and a missing file for our board at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9882 please?
Thanks,
Jamie
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: 14 April 2021 08:35
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] Timeframe on release/approval
Hi,
TF-M release cadence is 4 month. In theory 1.4 release is around July.
Tamas
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: 2021. április 14., szerda 8:10
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Minos/David/Shebu,
Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4?
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 13 April 2021 17:57
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] Timeframe on release/approval
Hi Jamie,
My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon.
Regards,
Shebu
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, April 13, 2021 3:14 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
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 <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
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.
Hi Shebu,
Just as a FYI TF-M 1.3 has already been integrated into Zephyr and will be
part of the 2.6.0 release, scheduled for the end of the month.
If TF-M 1.4 happens in July, that will likely be the version that Zephyr
2.7.0 will likely use, which will be an LTS release.
Kevin
On Tue, 13 Apr 2021 at 18:57, Shebu Varghese Kuriakose via TF-M <
tf-m(a)lists.trustedfirmware.org> wrote:
> Hi Jamie,
>
>
>
> My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2
> was integrated and I assume v1.3 will be done sometime soon.
>
>
>
> Regards,
>
> Shebu
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> * On Behalf Of *David
> Hu via TF-M
> *Sent:* Tuesday, April 13, 2021 3:14 AM
> *To:* tf-m(a)lists.trustedfirmware.org
> *Cc:* nd <nd(a)arm.com>
> *Subject:* Re: [TF-M] Timeframe on release/approval
>
>
>
> Hi Jaime,
>
>
>
> Anton and I have reviewed your patch. Please check our comments on the
> patch.
>
> I believe other reviewers will provide their input as well soon.
>
> Although it is difficult to guarantee the timeframe in TF-M as in other
> open-source project, it will speed up the review process if reviewers’
> comments can be addressed in time. 😊
>
>
>
> Best regards,
>
> Hu Ziji
>
>
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Minos
> Galanakis via TF-M
> *Sent:* Tuesday, April 13, 2021 12:09 AM
> *To:* tf-m(a)lists.trustedfirmware.org
> *Cc:* nd <nd(a)arm.com>
> *Subject:* Re: [TF-M] Timeframe on release/approval
>
>
>
> Hi Jamie,
>
>
>
> Thank you very much for your interest in supporting for TF-M in your
> platform. Since you are contributing a new platform, I would recommend that
> you read the Trusted Firmware maintenance process
> <https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>,
> for further details on the process.
>
>
>
> To answer your questions about the timeframe, that really depends on
> various factors, such as how busy the maintainers of this code are, weather
> there is a release pending which would follow a code freeze, and how
> complicated the changes are. I don't believe it is easy to estimate a
> figure.
>
>
>
> Regards,
>
> Minos
>
>
> ------------------------------
>
> *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie
> Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org>
> *Sent:* 12 April 2021 09:40
> *To:* tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
> *Subject:* [TF-M] Timeframe on release/approval
>
>
>
> Hi,
>
> I submitted a patch to add our board to the Trusted Firmware-M repository
> under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508
> and was wondering on timeframes for receiving comments or having the pull
> request accepted? We want to have our board added to Zephyr RTOS and for
> that, we need the board in TF-M and pulled into the Zephyr version of this
> repository (I’m not sure if they can pull any version of the code or if
> they only pull full release versions e.g. 1.3.0), are there any comments on
> this and does anyone have any idea of a rough estimate the time required
> from now to get the base files into the zephyr version of the repository so
> we can submit our boards file?
>
> Thanks,
>
> Jamie
>
> 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.
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
Hi,
Would it be possible to get some quick reviews on some fixes and a missing file for our board at https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9882 please?
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: 14 April 2021 08:35
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Timeframe on release/approval
Hi,
TF-M release cadence is 4 month. In theory 1.4 release is around July.
Tamas
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M
Sent: 2021. április 14., szerda 8:10
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Timeframe on release/approval
Hi Minos/David/Shebu,
Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4?
Thanks,
Jamie
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M
Sent: 13 April 2021 17:57
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] Timeframe on release/approval
Hi Jamie,
My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon.
Regards,
Shebu
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, April 13, 2021 3:14 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jaime,
Anton and I have reviewed your patch. Please check our comments on the patch.
I believe other reviewers will provide their input as well soon.
Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M
Sent: Tuesday, April 13, 2021 12:09 AM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: Re: [TF-M] Timeframe on release/approval
Hi Jamie,
Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process.
To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure.
Regards,
Minos
________________________________
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 <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Sent: 12 April 2021 09:40
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>
Subject: [TF-M] Timeframe on release/approval
Hi,
I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file?
Thanks,
Jamie
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.
I think at the moment that wouldn't get caught by the flow control countermeasures. However, we did have an idea for an improvement (which didn't get implemented), that should resolve it.
At the moment, calling a function with FIH_CALL increases the flow control counter by 1. The alternative we considered was to instead increase the counter by a value that was generated based on the function that was called.
Exactly how to generate this number is tricky, since we can't really implement a proper hash function in the preprocessor. The compromise we came to was that we could increase it by sizeof(__func__), (the length of the function name). This is accessible to both the call and the ret, and should be reasonably easily implementable. This wouldn't solve your issue immediately, but one function could then be renamed to be of different length.
Another alternative is that you could manually increment and check the flow-control counter, though having to do that manually isn't ideal.
Do either of these options seem reasonable?
Raef
________________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Michel JAOUEN via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 30 April 2021 13:55
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] [FIH lib] : fih question on a specific fault injection
Hello
I start using FIH library and I doubt that it can solve following fault injection :
Here are 2 tests function being placed by linker very closed from each other to make possible
to jump from test_1 start address to test_2 start address with a fault injection.
fih_int test_1(void)
{
fih_int fih_rc = FIH_FAILURE;
fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS);
FIH_RET(fih_rc);
}
fih_int test_2(void)
{
fih_int fih_rc = FIH_FAILURE;
fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS);
FIH_RET(fih_rc);
}
Is the following able to detect that code return from test_2 instead of test_1 after such fault ?
FIH_CALL(test_1());
if (fih_not_eq(fih_rc, fih_int_encode(TFM_HAL_SUCCESS))) {
tfm_core_panic();
}
Best regards
Michel
Hello
I start using FIH library and I doubt that it can solve following fault injection :
Here are 2 tests function being placed by linker very closed from each other to make possible
to jump from test_1 start address to test_2 start address with a fault injection.
fih_int test_1(void)
{
fih_int fih_rc = FIH_FAILURE;
fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS);
FIH_RET(fih_rc);
}
fih_int test_2(void)
{
fih_int fih_rc = FIH_FAILURE;
fih_rc = fih_int_encode(TFM_PLAT_ERR_SUCCESS);
FIH_RET(fih_rc);
}
Is the following able to detect that code return from test_2 instead of test_1 after such fault ?
FIH_CALL(test_1());
if (fih_not_eq(fih_rc, fih_int_encode(TFM_HAL_SUCCESS))) {
tfm_core_panic();
}
Best regards
Michel
Hi Suresh,
Secure Enclave and dual-cpu so far only support IPC model.
Therefore Profile Medium and Profile Large can run on SE and dual-cpu platforms.
Besides, Profile Large by default enables Fault Injection Hardening library. It requires platform to support Fault Injection Hardening.
The secure firmware binary size may vary with different underlying inter-core communication and assigned resources.
Best regards,
Hu Ziji
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M
Sent: Friday, April 30, 2021 3:40 PM
To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] Questions on Musca-B1 SE implementation
Hi Suresh,
Here is a link how to build images to Musca-B1 SE:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
I have built with GCC and MinSizeRel build type:
Profile Medium:
Memory region Used Size Region Size %age Used
FLASH: 101464 B 381 KB 26.01%
RAM: 61304 B 64 KB 93.54%
[100%] Built target tfm_s
Profile Large:
Memory region Used Size Region Size %age Used
FLASH: 170448 B 381 KB 43.69%
RAM: 62980 B 64 KB 96.10%
[ 97%] Built target tfm_s
The profiles means different capabilities of TF-M, they were introduced to support constrained devices as well, with limited capability.
There is a detailed description about the profiles here:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…
BR,
Tamas
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: 2021. április 29., csütörtök 21:49
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] Questions on Musca-B1 SE implementation
I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1.
We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it.
Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what's are the estimated latencies of boot on SE with all the Flash accesses, etc.
https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdfhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
Any info on this would be appreciated.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
I am following up on a question that came up on the TFM Core and MCUBoot image sizes that is built for SE on Musca-B1.
We are trying to figure out the resource requirements for SE, to be able to host the TF-M as suggested in the slides below. Wondering if anyone throw more light on the RAM/FLASH requirements for it.
Also, does the TFM profile small/medium/large map to this at all or is it different from them. Also, what's are the estimated latencies of boot on SE with all the Flash accesses, etc.
https://www.trustedfirmware.org/docs/Musca-B1-Secure-Enclave-Solution.pdfhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…
Any info on this would be appreciated.
thanks
Suresh Marisetty
Infineon Semiconductor Corporation
Hi all,
The patch sets to decouple NS code from TF-M secure part have been merged.
Sorry for the early merge as other pending patches depend on this patch set.
Please rebase your patches if build reports an error about conflicting types of `tfm_ns_interface_init()`.
Sorry for any inconvenience.
If this decoupling brings any issue in NS integration with TF-M, sorry about the trouble and I'd appreciate it if you can share the issue details.
Any further comment or suggestion 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: Tuesday, April 27, 2021 11:50 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface
Hi all,
Thanks a lot for all your review and comments!
I'd like to merge the patch sets *this Friday* if there is no further critical comment.
Please feel free to continue to review and comment.
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: Thursday, April 15, 2021 4:12 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] [Ask for review] Decouple NS specific code from TF-M NS interface
Hi all,
May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface?
https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta…
The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation.
https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2…
The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface.
Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations.
Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation.
Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo.
This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations.
Any comment is welcome!
Best regards,
Hu Ziji
