- TF-M - lists.trustedfirmware.org

[RFC] twin cpu bootloader design document

by Christopher Brand

Hi, I've posted a design document for bootloader changes to support twin cpu at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ Comments appreciated! Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 7 months

1
0
0 0

[Core Patch] Core: switch signal wait object to 'condition'

by Ken Liu (Arm Technology China)

Hi, I will update the wait object from 'event' to 'condition'. This is mainly for fixing the issue: https://developer.trustedfirmware.org/T273 'event' is actually a depth 1 semaphore, which is not good enough for signals synching case. Involve a simpler sync object 'condition' for signals (and client ACKs): https://review.trustedfirmware.org/c/trusted-firmware-m/+/712 Please help to check if you are interested in it. Thanks -Ken

6 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi Alan, Expected to be merged before end of Mar 13th if there is no more raised concern ;) -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Tuesday, March 12, 2019 11:27 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' > is happening > > Yay! When? > > > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf- > m(a)lists.trustedfirmware.org> wrote: > > > > Hi TF-M Subscribers, > > The branch 'feature-ipc' is going to be merged into 'master', and here is the > patch: > > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > > > After the merging, the IPC feature will be available in the 'master' branch, > future updates on the IPC part will happen in 'master' branch, too. > > For those patches pushed towards 'feature-ipc' will be reviewed and we > suggest push new patchset to 'master' branch. > > > > Please reply to this thread without hesitation if there are any questions. > > > > Thanks. > > > > -Ken > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by DeMars, Alan

Yay! When? > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi TF-M Subscribers, > The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. > For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. > > Please reply to this thread without hesitation if there are any questions. > > Thanks. > > -Ken > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 7 months

1
0
0 0

Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi TF-M Subscribers, The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. Please reply to this thread without hesitation if there are any questions. Thanks. -Ken

6 years, 7 months

1
0
0 0

TF-M v1.0-Beta Blog

by Shebu Varghese Kuriakose

Hi, Here is a blog on the recent TF-M tag v1.0-Beta and how it enables PSA certification https://www.trustedfirmware.org/blog/Trusted-Firmware-M-v10-Beta-Enabling-P… Regards, Shebu

6 years, 7 months

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Oh, and a little terminology comment about the Trusted non-volatile (NV) counters. This section should use "increase" and "decrease" not "increment" and "decrement". There is no requirement that the counter only be incremented (having 1 added to the value), only that it be set to a larger value than the current value. You should probably also add a discussion as to how testing will be done with a HW security counter. Again, my suggestion is to not add an additional counter, but just use the existing version field (minus the build number) as the security counter value. David

6 years, 7 months

1
0
0 0

Trusted boot - rollback protection

by Tamas Ban

Hi all, Please see the following link for a design proposal on anti-rollback protection in trusted boot: https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Comments are welcome! Regards Tamas Ban

6 years, 7 months

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Andrew Thoelke

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.

6 years, 7 months

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Ken Liu (Arm Technology China)

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.

6 years, 7 months

1
0
0 0

multiple services within the same SP

by DeMars, Alan

In a multi-service SP, how does the SP know which SID has been used to connect to it?

6 years, 8 months

1
0
0 0

Re: [TF-M] META: TF-M Mailing list configuration

by Bill Fletcher

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 >

6 years, 8 months

1
0
0 0

META: TF-M Mailing list configuration

by David Brown

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

6 years, 8 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

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

6 years, 8 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Thomas Törnblom

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>

6 years, 8 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Antonio De Angelis

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.

6 years, 8 months

1
0
0 0

Re: [TF-M] SecureFault when starting the OS

by Miklos Balint

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.

6 years, 8 months

1
0
0 0

SecureFault when starting the OS

by Thomas Törnblom

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>

6 years, 8 months

1
0
0 0

Some comments on twincpu mailbox design

by David Hu (Arm Technology China)

Hi Danny, Could you please check my comments on [Mailbox design](https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/mailbo… in below? I’d like to discuss about some high-level designs at the very first time. We can discuss about details later. 😊 1. As designed in Concepts section, secure core has a single dispatcher thread, which is the main thread on the secure core. AFAIK, there is no such main thread in current TF-M Inter-Process Communication model implementation. Do you mind taking a look at the section "Interaction in thread model" in our [TF-M presentation](https://events.linuxfoundation.org/wp-content/uploads/2017/12… On the other hand, implementing a dedicated thread in TF-M to handling the mailbox events can be a solution. But it might also bring some difficulties in implementation. I'd like to discuss in detail with Transport Layer together. 2. I like the concept of mailbox event. One of the key points is, after the information carried via mailbox arrives in TF-M, how to deliver it to TF-M core. We can have further discussions on the details. 3. PSA Firmware Framework specifies the parameters and return value for PSA Client APIs. Do you think if it is necessary to cover the mailbox message structure containing information of parameters and return value in mailbox design? Thank you. Best regards, Hu Ziji

6 years, 8 months

2
4
0 0

Re: [TF-M] What is the behavior of SPM between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`

by Ken Liu (Arm Technology China)

Hi Alan, From my point of view, TZ_StoreContext_S() indicates the non-secure thread accesses secure service is getting switching out, no one should access secure services before a calling of TZ_LoadContext_S(). This case could be covered in below condition in PSA FF client APIs (Picked on line from page 49 of PSA FF 1.0 beta0): "Calling psa_connect() is a fatal error and will not return if any of the following conditions are met: * ... * The caller is not authorized to access the RoT Service, see RoT Service access control on page 28. * ..." Pining the calling non-secure thread is the proper way - which means, 'Does not return' to the non-secure thread in this case. There should be no such an API to peek the status of SPM from caller out of SPM. And there should be a similar API for SPM (only) to retrieve the current MemoryID (or information could be represented as MemoryID). BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Thursday, February 21, 2019 10:54 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] What is the behavior of SPM between `TZ_StoreContext_S()` and > `TZ_LoadContext_S()` > > Are calls to psa_connect/call/close allowed after `TZ_StoreContext_S()` has > been called but before `TZ_LoadContext_S()` is called? If not, does that result in > a panic or simply error return codes? > > Is there a secure-side SPM API that can be invoked from a custom veneer > function to determine if the SPM is in the zone between `TZ_StoreContext_S()` > and `TZ_LoadContext_S()`? > > Is there an API that returns the current MemoryId? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 8 months

1
0
0 0

What is the behavior of SPM between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`

by DeMars, Alan

Are calls to psa_connect/call/close allowed after `TZ_StoreContext_S()` has been called but before `TZ_LoadContext_S()` is called? If not, does that result in a panic or simply error return codes? Is there a secure-side SPM API that can be invoked from a custom veneer function to determine if the SPM is in the zone between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`? Is there an API that returns the current MemoryId? Alan

6 years, 8 months

1
0
0 0

Re: [TF-M] Musca-A SAU setup issues

by Mate Toth-Pal

Hi Thomas, (The code snippets are from the commit with hash 5c1756fbab6097f5688583d11dea5d1271d2d774 on https://review.trustedfirmware.org . I only added some comments at certain points) This symptom is usually caused by a misconfigured MPC. The MPC initialisation is also called from platform\ext\target\musca_a\spm_hal.c: ---------- 8< ---------- void tfm_spm_hal_init_isolation_hw(void) { /* Configures non-secure memory spaces in the target */ sau_and_idau_cfg(); mpc_init_cfg(); /* <- initialise MPC */ ppc_init_cfg(); } ---------- >8 ---------- Looking at mpc_init_cfg: ---------- 8< ---------- void mpc_init_cfg(void) { /* ... */ Driver_QSPI_MPC.Initialize(); Driver_QSPI_MPC.ConfigRegion(memory_regions.non_secure_partition_base, memory_regions.non_secure_partition_limit, ARM_MPC_ATTR_NONSECURE); /* ... */ /* Lock down the MPC configuration */ Driver_QSPI_MPC.LockDown(); /* ... */ /* Add barriers to assure the MPC configuration is done before continue * the execution. */ __DSB(); __ISB(); } ---------- 8< ---------- It is possible to change the MPC behaviour, to raise a bus fault on invalid access instead of the RAZ/WI behaviour, by setting the CFG_SEC_RESP bit in the MPC's control register. You should do something like this after Driver_QSPI_MPC initialisation (see https://developer.arm.com/products/architecture/cpu-architecture/m-profile/… ): ---------- 8< ---------- uint32_t mpc_ctrl; Driver_QSPI_MPC.GetCtrlConfig(&mpc_ctrl); Driver_QSPI_MPC.SetCtrlConfig(mpc_ctrl | 0x10); ---------- 8< ---------- If you don't get the bus fault after this, further troubleshooting is needed. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 15 February 2019 15:57 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Musca-A SAU setup issues I am working on porting TF-M to the IAR Embedded Workbench for ARM (EWARM) toolchain and I'm having some issues getting it to start properly. I started out 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 CMSIS packs and I've had to fix things in all of the packs to make the project build with our compiler, some things just to add our tools, some things that were just gcc:isms that are non standard-C. The TF-M code is based on a snapshot of https://git.trustedfirmware.org/trusted-firmware-m.git repository of the following hash: 5c1756fbab6097f5688583d11dea5d1271d2d774 I know that some of these packs are old and I'm also working on a port of the bits on trustedfirmware.org, but I would like to bring the old version up first. The (current) issue I have is that the NS code region becomes inaccessible from the secure part after setting the SAU up and I assume I am missing something. in tfm_core_init() there are calls to: --- tfm_spm_hal_init_isolation_hw(); configure_ns_code(); --- tfm_spm_hal_init_isolation_hw() calls sau_and_idau_cfg(), which sets up: --- /* Configures SAU regions to be non-secure */ SAU->RNR = TFM_NS_REGION_CODE; SAU->RBAR = (memory_regions.non_secure_partition_base & SAU_RBAR_BADDR_Msk); SAU->RLAR = (memory_regions.non_secure_partition_limit & SAU_RLAR_LADDR_Msk) | SAU_RLAR_ENABLE_Msk; --- After this piece is run, the NS vector table becomes all zeros when viewed from secure mode. This causes the configure_ns_code() call above to fail to pick up the ns_msp and ns_entry addresses, they become 0. If I swap the calls around so they become: --- configure_ns_code(); tfm_spm_hal_init_isolation_hw(); --- then ns_msp and ns_entry are picked up OK. How is this supposed to work? When the SAU is setup I get RAZ/WI when accessing NS memory from S mode, the other way around results is a security violation, which is properly handled by the SecureFault_Handler(). What am I missing? I run into other problems later, but that may very well a consequence of earlier issues. 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

6 years, 8 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by DeMars, Alan

My concern was the value one would provide for the "line_num" field within the manifest. The SYSTICK uses vector 15 which I believe would correspond to "line_num" = -1. I'm not sure the design accommodates negative line_nums. Also, disabling the SYSTICK interrupt while servicing its interrupt can't be handled in the normal way user IRQs are disabled. Special case code would be required in the SPM to support the SYSTICK as a secure partition interrupt. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:34 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SYSTICK ownership Hi Alan, From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure SYSTICK timer > and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 8 months

1
0
0 0

Re: [TF-M] SYSTICK ownership

by Ken Liu (Arm Technology China)

Hi Alan, From your description, it looks like you want to use secure SYSTICK as an interrupt for Secure Partition, is this correct? In this case, it is similar to the secure interrupt usage. Since the interrupt handling is under developing, I will add a note in the task to remind how we could add SYSTICK as an interrupt in the manifest. BR -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:02 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] SYSTICK ownership > > If not used anywhere else, can a Secure Partition own the secure SYSTICK timer > and its interrupt? > If so, how is it specified in the SP manifest? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 8 months

1
0
0 0

Re: [TF-M] interrupts not supported on feature-ipc branch?

by DeMars, Alan

Thanks! I'll check back. -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Monday, February 18, 2019 5:16 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] interrupts not supported on feature-ipc branch? Hi Alan, There would be a merge to master in recent days; so master branch will support PSA IPC soon. The interrupts for IPC is under developing, you can check the roadmap to know the plan. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Saturday, February 16, 2019 7:37 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] interrupts not supported on feature-ipc branch? > > I guess interrupts are only supported on the master branch. > > When will the master branch support PSA IPC? > > Or, when will the feature-ipc branch support interrupts? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M