Hi Alan,
I can answer this from the PSA Firmware Framework specification point of view, Ken (or others in the TF-M team) can clarify how closely the TF-M behaviour matches this.
In the manifest each service has a "signal" attribute which is a C identifier that is given the signal value for that service. The value is allocated by the TF-M tools and should be available to the SP source code via a generated header file - the specification places these definitions in the psa_manifest/<manifestfilename>.h header file, matching the name of the manifest file itself.
When the SP receives a set of signals from psa_wait(), it can identify which signals are asserted using these identifiers to test the signal bits.
The example RoT Service in Appendix D of the PSA Firmware Framework demonstrates this.
Regards,
Andrew
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M
Sent: 08 March 2019 13:52
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] multiple services within the same SP
In a multi-service SP, how does the SP know which SID has been used to connect to it?
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Alan,
Services are listed in SP. SPM could enumerate the services in a SP by the list.
You can check the member variable ' service_list' of ' tfm_spm_ipc_partition_t' to know details.
-Ken
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars,
> Alan via TF-M
> Sent: Friday, March 8, 2019 9:52 PM
> To: tf-m(a)lists.trustedfirmware.org
> Subject: [TF-M] multiple services within the same SP
>
> In a multi-service SP, how does the SP know which SID has been used to connect
> to it?
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi David,
Thanks for raising this. I'll contact you directly to review the Mailman
configuration.
Regards
Bill
On Thu, 28 Feb 2019, 05:04 David Brown via TF-M, <
tf-m(a)lists.trustedfirmware.org> wrote:
> I have noticed that this mailing list seems to be configured in a
> non-ideal way.
>
> Primarily, the messages are sent from the list address itself, and a
> reply-to header is inserted for the original sender. This at least
> often will allow someone to reply to the original sender.
>
> There are a few problems with this. One is that this tends to break
> messages that have been copied to more than one list, especially for
> recipients who subscribe to both lists. Admittedly it is better than
> the all-to-common practice of setting Reply-to to the list itself,
> which effectively steals all replies from any other recipients or
> lists that were originally included.
>
> Secondly, however, this kind of violates the intent of the reply-to
> field, which was intended for the originator of the message to be able
> to give an alternative address they wish for replies to go to.
>
> I don't know how this list is hosted, and usually this kind of
> configuration results from an ISP that rejects messages. But, I know
> a lot of mailing lists are managed with mailman without these
> problems, so it should be possible to get this working in a more
> homogenous way.
>
> Lists admins, feel free to contact me if you want any assistance in
> trying to configure the list better.
>
> Thanks,
> David
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
I have noticed that this mailing list seems to be configured in a
non-ideal way.
Primarily, the messages are sent from the list address itself, and a
reply-to header is inserted for the original sender. This at least
often will allow someone to reply to the original sender.
There are a few problems with this. One is that this tends to break
messages that have been copied to more than one list, especially for
recipients who subscribe to both lists. Admittedly it is better than
the all-to-common practice of setting Reply-to to the list itself,
which effectively steals all replies from any other recipients or
lists that were originally included.
Secondly, however, this kind of violates the intent of the reply-to
field, which was intended for the originator of the message to be able
to give an alternative address they wish for replies to go to.
I don't know how this list is hosted, and usually this kind of
configuration results from an ISP that rejects messages. But, I know
a lot of mailing lists are managed with mailman without these
problems, so it should be possible to get this working in a more
homogenous way.
Lists admins, feel free to contact me if you want any assistance in
trying to configure the list better.
Thanks,
David
Hi Thomas,
Thanks for the feedback. An additional question from me to understand better the issue: are you rebuilding RTX from source, not using the pre-built binaries distributed with CMSIS_5?
Since this commit: https://github.com/ARM-software/CMSIS_5/commit/8bce76b03565359f31cd20ed86c2… CMSIS_5 has changed from using __DOMAIN_NS to DOMAIN_NS macro for better MISRA compliance. I think to officially support newer releases of CMSIS, we should update our instructions and define DOMAIN_NS in addition to __DOMAIN_NS, as this define will come into picture for integrations which actually rebuild RTX from the CMSIS_5 repo sources.
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 26 February 2019 09:58
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] SecureFault when starting the OS
Thanks Miklos and Antonio,
You were both spot on.
Turned out I had not define DOMAIN_NS=1, which change the last byte from FD to BC.
I need to figure out why I need to add that when the documentation says
__DOMAIN_NS=1 should be sufficient.
Cheers,
/Thomas
Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M:
> Hi Thomas,
>
> As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10).
>
> In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md .
>
> Thanks,
> Antonio
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> Thomas Törnblom via TF-M
> Sent: 25 February 2019 15:34
> To: tf-m(a)lists.trustedfirmware.org
> Subject: [TF-M] SecureFault when starting the OS
>
> In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code.
>
> I'm now running into an issue where I get a SecureFault when attempting to start the OS.
>
> The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault.
>
> SFSR indicates that it is an INVER (Invalid Exception Return):
> ---
> Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are:
> 0 Error has not occurred.
> 1 Error has occurred.
> --
>
> LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception.
>
> What am I missing here?
>
> Is the OS supposed to be started from NS mode?
>
> I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0,
> ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.
>
> Thanks,
> /Thomas
>
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
> Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems
> <http://www.twitter.com/iarsystems>
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Thanks Miklos and Antonio,
You were both spot on.
Turned out I had not define DOMAIN_NS=1, which change the last byte from
FD to BC.
I need to figure out why I need to add that when the documentation says
__DOMAIN_NS=1 should be sufficient.
Cheers,
/Thomas
Den 2019-02-25 kl. 17:13, skrev Antonio De Angelis via TF-M:
> Hi Thomas,
>
> As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10).
>
> In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md .
>
> Thanks,
> Antonio
>
> -----Original Message-----
> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
> Sent: 25 February 2019 15:34
> To: tf-m(a)lists.trustedfirmware.org
> Subject: [TF-M] SecureFault when starting the OS
>
> In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code.
>
> I'm now running into an issue where I get a SecureFault when attempting to start the OS.
>
> The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault.
>
> SFSR indicates that it is an INVER (Invalid Exception Return):
> ---
> Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are:
> 0 Error has not occurred.
> 1 Error has occurred.
> --
>
> LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception.
>
> What am I missing here?
>
> Is the OS supposed to be started from NS mode?
>
> I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0,
> ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.
>
> Thanks,
> /Thomas
>
>
> *Thomas Törnblom*, /Product Engineer/
> IAR Systems AB
> Box 23051, Strandbodgatan 1
> SE-750 23 Uppsala, SWEDEN
> Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
> E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
> Website: www.iar.com <http://www.iar.com>
> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Thomas,
As you correctly identified, the value of the EXC_RETURN is not appropriate for the state the exception was taken from. As a quick double check, you can set it manually from a debugger to 0xFFFFFFBC before the exception return takes place and in that case the exception return will happen correctly. You can find more details on the meaning of each bit of the EXC_RETURN register at the following link: https://static.docs.arm.com/100701/0100/armv8_m_processor_exception_handlin… (section 1.10).
In general, once TF-M has finished booting and has jumped to the NS state, the OS initialisation should take place (you can see as an example in the NS app how the RTX kernel initialisation happens). If the OS manipulates directly the Link Register, it needs to be aware that it's running from the NS state (this can imply a build time configuration step) so that it will set up correctly the default value of the EXC_RETURN when an exception happens. You can find more details in docs/user_guides/os_migration_guide_armv8m.md .
Thanks,
Antonio
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 25 February 2019 15:34
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] SecureFault when starting the OS
In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code.
I'm now running into an issue where I get a SecureFault when attempting to start the OS.
The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault.
SFSR indicates that it is an INVER (Invalid Exception Return):
---
Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are:
0 Error has not occurred.
1 Error has occurred.
--
LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception.
What am I missing here?
Is the OS supposed to be started from NS mode?
I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0,
ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.
Thanks,
/Thomas
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Thomas,
According to TF-M's design, an RTOS is meant to be started/run in NS.
If a non-secure SVC handler is called from thread mode (PSP, no FP, default stacking), the value of LR should be 0xFFFF_FFBC on exception entry.
In my experience some v7-M RTOS implementations don't save the EXC_RETURN value on SVC entry but have a default value hard-coded at SVC exit. In a v7-M system the default EXC_RETURN value (assuming no SVC from handlers, and PSP used for thread mode) would be 0xFFFF_FFFD as you describe below, but that's not the case for a NS RTOS in v8-M. (The two bits that are different are EXC_RETURN.S (bit [6]) to indicate NS stack, and EXC_RETURN.ES (bit [0]) to indicate that the Exception was taken to NS)
A recommended and future-proof solution is for the RTOS to save the EXC_RETURN value stored in LR on SVC entry, and when returning from the SVC, to restore that and branch, or, if a switch is needed from MSP to PSP, to set EXC_RETURN.SPSEL as needed, but leave the rest of the EXC_RETURN value unchanged.
Let me know if this helps, or please provide further details if I failed to catch the root cause.
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M
Sent: 25 February 2019 16:34
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] SecureFault when starting the OS
In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so that the startup will properly switch to the NS code.
I'm now running into an issue where I get a SecureFault when attempting to start the OS.
The idle and timer threads have been configured and the timer thread has been put on run.curr and SVC_Exit issues a BX LR, which results in a SecureFault.
SFSR indicates that it is an INVER (Invalid Exception Return):
---
Invalid exception return flag. This can be caused by EXC_RETURN.DCRS being set to 0 when returning from an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1 when returning from an exception in the Non-secure state. The possible values of this bit are:
0 Error has not occurred.
1 Error has occurred.
--
LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it appears to be the second condition that triggered the exception.
What am I missing here?
Is the OS supposed to be started from NS mode?
I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0,
ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.
Thanks,
/Thomas
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
In my work to port TF-M to IAR EWARM I have now gotten the MPC set up so
that the startup will properly switch to the NS code.
I'm now running into an issue where I get a SecureFault when attempting
to start the OS.
The idle and timer threads have been configured and the timer thread has
been put on run.curr and SVC_Exit issues a BX LR, which results in a
SecureFault.
SFSR indicates that it is an INVER (Invalid Exception Return):
---
Invalid exception return flag. This can be caused by EXC_RETURN.DCRS
being set to 0 when returning from
an exception in the Non-secure state, or by EXC_RETURN.ES being set to 1
when returning from an exception
in the Non-secure state. The possible values of this bit are:
0 Error has not occurred.
1 Error has occurred.
--
LR was 0xfffffffd (DCRS=1, ES=1) and the security bit was cleared, so it
appears to be the second condition that triggered the exception.
What am I missing here?
Is the OS supposed to be started from NS mode?
I am still using the ARM.TFM.1.1.0, ARM.Musca_A1_BSP.2.0.0,
ARM.mbedTLS.1.3.1 and ARM.CMSIS.5.5.0-dev2 packs.
Thanks,
/Thomas
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
