- TF-M - lists.trustedfirmware.org

by Miklos Balint

Hi Andrej, For the SVC issue - that should be easy to resolve: The only point at which the NS application stored in the repo uses SVC is when TFM_NS_CLIENT_IDENTIFICATION is enabled. If your scope is a feasibility study with any OS you can turn off this feature by adding set (TFM_NS_CLIENT_IDENTIFICATION OFF) to your Config*.cmake build configuration or toggle the corresponding line in CommonConfig.cmake to OFF to turn it off globally for all build configs in your repo. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 25 April 2019 09:46 To: TF-M(a)lists.trustedfirmware.org Subject: [TF-M] TFM and FreeRTOS Hello, Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TFM and FreeRTOS

by Andrej Butok

Hello, Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study? I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs. Thanks, Andrej

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, OK. We will disable IPC in the regression tests, till it is fixed. Thank you, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Wednesday, April 24, 2019 9:52 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, This is caused by one of the working model changing patch: 4d66dc3cca0d8c1eff5a3a41692cf01d69eae6ca. The concept of this series changes is: IPC compatible partition is supported only if IPC working model takes place; and library model partitions works for library working model. Before 1.5 weeks ago IPC model could co-exists with library model so the regression works but it is not good -- we should not enable co-existing of two models since it is a waste of resources. We are working on an a workaround to avoid this problem at first by disable library model test while IPC model is selected; and later on patches will make the test framework under proper way for each working model. Thanks. -Ken > -----Original Message----- > From: Andrej Butok <andrey.butok(a)nxp.com> > Sent: Wednesday, April 24, 2019 3:35 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: RE: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Ken, > > The fix has fixed the bus fault. Thanks > > But there are some issues when to run the TFM regression tests > (defined CORE_TEST_IPC and TFM_PSA_API) > > I am getting Security violation > SVC_Handle()=>tfm_core_partition_request_svc_handler()=>tfm_core_sfn_r > equ est_handler()=>tfm_secure_api_error_handler(), > > The log: > > [Sec Thread] Secure image initializing! > [Sec Thread] hello! this is ipc client test sp! > [Sec Thread] Connect success! > [Sec Thread] Call success! > > NS code is running... > [Sec Error] Unauthorized service request! > [Sec Error] Security violation when calling secure API > > > Could you run the regression tests and check if everything is OK. > 1.5 week ago, even when IPC was enabled, all regression tests passed. > Now they are passing only when IPC is disabled. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Wednesday, April 24, 2019 9:02 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi, > The fix for this problem has been logged here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > lope > r.trustedfirmware.org%2FT327&data=02%7C01%7Candrey.butok%40nxp.c > om%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636916861232914034&sdata=Zq54%2FpI%2FyTtyv > K5aUhWwdU%2FQGPIhJKKT36Ue8Pnop1U%3D&reserved=0 > And the patch is here: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frevi > ew.tr > ustedfirmware.org%2Fc%2Ftrusted-firmware- > m%2F%2B%2F922&data=02%7C01%7Candrey.butok%40nxp.com%7Ccf087 > 48223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C > 0%7C0%7C636916861232914034&sdata=i1A91n5gv6UocgRCcazmiClhH%2 > F%2BkB%2FxGGU%2FktWWjjLk%3D&reserved=0 > > I used a fake thread object to collect initial context to make > scheduler has an initial CURR_THRD. > This is because I need to avoid unnecessary condition checking while > context switch since CURR_THRD only equals to ZERO for ONCE time: > > ctx_switch: > If (pcurr) > Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, > &pnext- > >ctx, sizeof(pnext->ctx)): > > The TFM_ASSERT in source is another thing since they may get removed > in a release product. > > Please help to provide feedback on it if you see this patch. And I > will try to merge it after several +1/2 is collected since it is an hotfix patch. > > Thanks. > > -Ken > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, April 23, 2019 10:06 PM > > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Andrej, > > Ah, great finding! > > We moved the default IDLE thread into partition now so there is no > > default CUR_THRD at very start. > > I guess reverting the latest commit > > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > > Sorry I don't have working platform now so can not verify it. > > Will provide a fix soon. > > > > -Ken > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > > Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > > Sent: Tuesday, April 23, 2019 9:58 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Andrej, > > > > While trying to replicate your issue I have found a (maybe related) > > issue with ConfigCoreIPC.cmake and Regression enabled on the current > > tip, described by the following ticket: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve > lope > r.trustedfirmware.org%2FT326&data=02%7C01%7Candrey.butok%40nxp.c > om%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636916861232924039&sdata=3VroxNyRxDp6DK2Ir > fYjgoE%2BGi0tKJDQL5%2Bbm1UnRHA%3D&reserved=0 . We are > investigating if this can be related to the issue you're observing. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: 23 April 2019 14:50 > > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > > > Hi Ken, > > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is > > NULL, before the first tfm_thrd_context_switch() call. > > OR I have something wrong. > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > > Liu (Arm Technology China) via TF-M > > Sent: Tuesday, April 23, 2019 3:43 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links > > or attachments unless you recognize the sender and know the content is safe. > > > > > > > > Hi Andrej, > > Thanks for the investigation, we will take a look ASAP. > > > > The thread context is allocated statically in global which should > > not have chance to be NULL. If you have time for digging, you can > > put message in function > > './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. > > > > Thanks. > > > > -Ken > > ________________________________ > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > > Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> > > Sent: Tuesday, April 23, 2019 9:16 PM > > To: Antonio De Angelis > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > > Hi Antonio, > > > > We have own port for LPC55S69, so not sure if you are able to run it. > > But, the issues happens in general code (master branch, the latest > > current commit). Defined TFM_PSA_API, TFM_LVL = 1. > > The NULL parameter is causing fault in the first call of > > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an > > >issue on > > any platform. > > > > Thanks, > > Andrej > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Antonio De Angelis via TF-M > > Sent: Tuesday, April 23, 2019 3:02 PM > > To: tf-m(a)lists.trustedfirmware.org > > Cc: nd <nd(a)arm.com> > > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > > > WARNING: This email was created outside of NXP. DO NOT CLICK links > > or attachments unless you recognize the sender and know the content is safe. > > > > > > > > Hi Andrej, > > > > Could you provide us with instructions on how to replicate the issue > > you're observing? In particular, which build configuration you're > > building (.cmake), compiler, platform used and if it's observed on > > board or FVP/model? Also, are you able to identify the latest commit > > which was still working in your setup / identify the commit which > > brings in this > issue? > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: 23 April 2019 13:19 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: TF-M(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > > > Father investigation shows, that tfm_pendsv_do_schedule() calls > > tfm_thrd_context_switch() and passing pth_curr which is set to > > NULL, so it is causing memcpy() to 0 address => Bus Fault. > > So this code may not work properly. > > Please provide a fix. > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Andrej Butok via TF-M > > Sent: Tuesday, April 23, 2019 1:38 PM > > To: TF-M(a)lists.trustedfirmware.org > > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > > > Hello, > > > > After last commits on TFM master branch, when TFM_PSA_API is > > defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> > > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > > When TFM_PSA_API is not defined, everything is OK. > > Also, TFM examples were OK at least 2 weeks ago, even when > > TFM_PSA_API was defined. > > > > Is it known issue? Or something new (during last week) must be added > > into our target-specific code? > > > > Thanks, > > Andrej Butok > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > > W8P9wLM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > > W8P9wLM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trust > > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > > > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > > > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > > > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > > 2YPMo%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli > > st > > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Ca > > > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1 > d3bc2 > > > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 > 4%2BC > > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7Ccf08748223284a6870 > 8b08d6c882c0a6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 16861232924039&sdata=i4R04%2BCzqYsB2bIBHHVUI1aOMNSEVKJa17ABl > 1vamUM%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, The fix has fixed the bus fault. Thanks But there are some issues when to run the TFM regression tests (defined CORE_TEST_IPC and TFM_PSA_API) I am getting Security violation SVC_Handle()=>tfm_core_partition_request_svc_handler()=>tfm_core_sfn_request_handler()=>tfm_secure_api_error_handler(), The log: [Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! NS code is running... [Sec Error] Unauthorized service request! [Sec Error] Security violation when calling secure API Could you run the regression tests and check if everything is OK. 1.5 week ago, even when IPC was enabled, all regression tests passed. Now they are passing only when IPC is disabled. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Wednesday, April 24, 2019 9:02 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi, The fix for this problem has been logged here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… And the patch is here: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I used a fake thread object to collect initial context to make scheduler has an initial CURR_THRD. This is because I need to avoid unnecessary condition checking while context switch since CURR_THRD only equals to ZERO for ONCE time: ctx_switch: If (pcurr) Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, &pnext->ctx, sizeof(pnext->ctx)): The TFM_ASSERT in source is another thing since they may get removed in a release product. Please help to provide feedback on it if you see this patch. And I will try to merge it after several +1/2 is collected since it is an hotfix patch. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 10:06 PM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > Ah, great finding! > We moved the default IDLE thread into partition now so there is no > default CUR_THRD at very start. > I guess reverting the latest commit > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > Sorry I don't have working platform now so can not verify it. > Will provide a fix soon. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:58 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > > While trying to replicate your issue I have found a (maybe related) > issue with ConfigCoreIPC.cmake and Regression enabled on the current > tip, described by the following ticket: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… . We are investigating if this can be related to the issue you're observing. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: 23 April 2019 14:50 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > Hi Ken, > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is > NULL, before the first tfm_thrd_context_switch() call. > OR I have something wrong. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken > Liu (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 3:43 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > Thanks for the investigation, we will take a look ASAP. > > The thread context is allocated statically in global which should not > have chance to be NULL. If you have time for digging, you can put > message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to > show all thread context value of partitions. > > Thanks. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of > Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:16 PM > To: Antonio De Angelis > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Antonio, > > We have own port for LPC55S69, so not sure if you are able to run it. > But, the issues happens in general code (master branch, the latest > current commit). Defined TFM_PSA_API, TFM_LVL = 1. > The NULL parameter is causing fault in the first call of > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an > >issue on > any platform. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Tuesday, April 23, 2019 3:02 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > > Could you provide us with instructions on how to replicate the issue > you're observing? In particular, which build configuration you're > building (.cmake), compiler, platform used and if it's observed on > board or FVP/model? Also, are you able to identify the latest commit > which was still working in your setup / identify the commit which brings in this issue? > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: 23 April 2019 13:19 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > Father investigation shows, that tfm_pendsv_do_schedule() calls > tfm_thrd_context_switch() and passing pth_curr which is set to NULL, > so it is causing memcpy() to 0 address => Bus Fault. > So this code may not work properly. > Please provide a fix. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: Tuesday, April 23, 2019 1:38 PM > To: TF-M(a)lists.trustedfirmware.org > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > Hello, > > After last commits on TFM master branch, when TFM_PSA_API is defined, > the tfm examples finish in main()=>tfm_spm_init()=>....=> > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > When TFM_PSA_API is not defined, everything is OK. > Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API > was defined. > > Is it known issue? Or something new (during last week) must be added > into our target-specific code? > > Thanks, > Andrej Butok > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trust > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca > ndrey.butok%40nxp.com%7Ccf08748223284a68708b08d6c882c0a6%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R04%2BC > zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

2
1
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi, The fix for this problem has been logged here: https://developer.trustedfirmware.org/T327 And the patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/922 I used a fake thread object to collect initial context to make scheduler has an initial CURR_THRD. This is because I need to avoid unnecessary condition checking while context switch since CURR_THRD only equals to ZERO for ONCE time: ctx_switch: If (pcurr) Tfm_memcpy(&pcurr->ctx, pctx, sizeof(*pctx)); Tfm_memcpy(pctx, &pnext->ctx, sizeof(pnext->ctx)): The TFM_ASSERT in source is another thing since they may get removed in a release product. Please help to provide feedback on it if you see this patch. And I will try to merge it after several +1/2 is collected since it is an hotfix patch. Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 10:06 PM > To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > Ah, great finding! > We moved the default IDLE thread into partition now so there is no default > CUR_THRD at very start. > I guess reverting the latest commit > 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. > Sorry I don't have working platform now so can not verify it. > Will provide a fix soon. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De > Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:58 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Andrej, > > While trying to replicate your issue I have found a (maybe related) issue with > ConfigCoreIPC.cmake and Regression enabled on the current tip, described by > the following ticket: https://developer.trustedfirmware.org/T326 . We are > investigating if this can be related to the issue you're observing. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: 23 April 2019 14:50 > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > > Hi Ken, > May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, > before the first tfm_thrd_context_switch() call. > OR I have something wrong. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Tuesday, April 23, 2019 3:43 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > Thanks for the investigation, we will take a look ASAP. > > The thread context is allocated statically in global which should not have chance > to be NULL. If you have time for digging, you can put message in function > './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context > value of partitions. > > Thanks. > > -Ken > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej > Butok via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: Tuesday, April 23, 2019 9:16 PM > To: Antonio De Angelis > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault > > Hi Antonio, > > We have own port for LPC55S69, so not sure if you are able to run it. > But, the issues happens in general code (master branch, the latest current > commit). Defined TFM_PSA_API, TFM_LVL = 1. > The NULL parameter is causing fault in the first call of > tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL- > >state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on > any platform. > > Thanks, > Andrej > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Tuesday, April 23, 2019 3:02 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault > > WARNING: This email was created outside of NXP. DO NOT CLICK links or > attachments unless you recognize the sender and know the content is safe. > > > > Hi Andrej, > > Could you provide us with instructions on how to replicate the issue you're > observing? In particular, which build configuration you're building (.cmake), > compiler, platform used and if it's observed on board or FVP/model? Also, are > you able to identify the latest commit which was still working in your setup / > identify the commit which brings in this issue? > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: 23 April 2019 13:19 > To: Andrej Butok <andrey.butok(a)nxp.com> > Cc: TF-M(a)lists.trustedfirmware.org > Subject: Re: [TF-M] TFM_PSA_API =>BusFault > > Father investigation shows, that tfm_pendsv_do_schedule() calls > tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is > causing memcpy() to 0 address => Bus Fault. > So this code may not work properly. > Please provide a fix. > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: Tuesday, April 23, 2019 1:38 PM > To: TF-M(a)lists.trustedfirmware.org > Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault > > Hello, > > After last commits on TFM master branch, when TFM_PSA_API is defined, the > tfm examples finish in main()=>tfm_spm_init()=>....=> > tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). > When TFM_PSA_API is not defined, everything is OK. > Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API > was defined. > > Is it known issue? Or something new (during last week) must be added into our > target-specific code? > > Thanks, > Andrej Butok > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904331396&sdata=663%2F9XukXmp8lCoKUM6qEa4h5mxn6I9my0jh > W8P9wLM%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > edfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C594516635db840889 > 6ee08d6c7f19eeb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636 > 916237904341405&sdata=QvbSlGT7udwTcKcJajgtO8rvCvH0UJOMMqOJUc > 2YPMo%3D&reserved=0 > -- > 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 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Good, will wait for the official fix ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 4:06 PM To: TF-M(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, Ah, great finding! We moved the default IDLE thread into partition now so there is no default CUR_THRD at very start. I guess reverting the latest commit 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. Sorry I don't have working platform now so can not verify it. Will provide a fix soon. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi Andrej, Ah, great finding! We moved the default IDLE thread into partition now so there is no default CUR_THRD at very start. I guess reverting the latest commit 4dcae6f69db61af31316831d773e5d8777e9fbd3 should fix this problem. Sorry I don't have working platform now so can not verify it. Will provide a fix soon. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Antonio De Angelis via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://developer.trustedfirmware.org/T326 . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Antonio De Angelis

Hi Andrej, While trying to replicate your issue I have found a (maybe related) issue with ConfigCoreIPC.cmake and Regression enabled on the current tip, described by the following ticket: https://developer.trustedfirmware.org/T326 . We are investigating if this can be related to the issue you're observing. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 14:50 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Ken, May be context is static, but the CURR_THRD (p_curr_thrd) pointer is NULL, before the first tfm_thrd_context_switch() call. OR I have something wrong. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Tuesday, April 23, 2019 3:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Ken Liu (Arm Technology China)

Hi Andrej, Thanks for the investigation, we will take a look ASAP. The thread context is allocated statically in global which should not have chance to be NULL. If you have time for digging, you can put message in function './secure_fw/core/ipc/tfm_spm.c:tfm_spm_init()' to show all thread context value of partitions. Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Andrej Butok via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] [EXT] Re: TFM_PSA_API =>BusFault

by Andrej Butok

Hi Antonio, We have own port for LPC55S69, so not sure if you are able to run it. But, the issues happens in general code (master branch, the latest current commit). Defined TFM_PSA_API, TFM_LVL = 1. The NULL parameter is causing fault in the first call of tfm_thrd_context_switch(..., NULL,...) => tfm_memcpy(&NULL->state_ctx.ctxb, ...) => memcpy(wrong address), and should cause an issue on any platform. Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [EXT] Re: [TF-M] TFM_PSA_API =>BusFault WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

Re: [TF-M] TFM_PSA_API =>BusFault

by Antonio De Angelis

Hi Andrej, Could you provide us with instructions on how to replicate the issue you're observing? In particular, which build configuration you're building (.cmake), compiler, platform used and if it's observed on board or FVP/model? Also, are you able to identify the latest commit which was still working in your setup / identify the commit which brings in this issue? Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok <andrey.butok(a)nxp.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] TFM_PSA_API =>BusFault Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

Re: [TF-M] TFM_PSA_API =>BusFault

by Andrej Butok

Father investigation shows, that tfm_pendsv_do_schedule() calls tfm_thrd_context_switch() and passing pth_curr which is set to NULL, so it is causing memcpy() to 0 address => Bus Fault. So this code may not work properly. Please provide a fix. -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M(a)lists.trustedfirmware.org Subject: [EXT] [TF-M] TFM_PSA_API =>BusFault Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 6 months

1
0
0 0

TFM_PSA_API =>BusFault

by Andrej Butok

Hello, After last commits on TFM master branch, when TFM_PSA_API is defined, the tfm examples finish in main()=>tfm_spm_init()=>....=> tfm_thrd_context_switch()=>tfm_memcpy()=>BusFault_Handler(). When TFM_PSA_API is not defined, everything is OK. Also, TFM examples were OK at least 2 weeks ago, even when TFM_PSA_API was defined. Is it known issue? Or something new (during last week) must be added into our target-specific code? Thanks, Andrej Butok

6 years, 6 months

1
0
0 0

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

by Michel JAOUEN

For solving the placement in contiguous region. One possible solution is to modify image format as follow : header can contain manifest and ih_hdr_size still fixes payload start offset and TLV section starts after sizeof(struct image_header) Michel -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: lundi 15 avril 2019 16:53 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] FW: Trusted boot - rollback protection Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

General mailbox design for TF-M in dual core system

by David Hu (Arm Technology China)

Hi all, I post a design document for mailbox design for TF-M in dual core system. Could you please please take a look at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/general_mailbo… Any comment is welcome. :) Thank you. Best regards, Hu Ziji

6 years, 6 months

1
0
0 0

Re: [TF-M] TF-M ARM GCC Optimization issue

by Antonio De Angelis

Hi, We have a candidate fix for issues reported with -Os builds with IPC mode builds, available here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/882 could you please help verify if this fixes the issue you're seeing? Note that also with this patch, the Secure side of SST regression in IPC mode fails, but that is another issue that we have identified and we have a separate patch which will be ready shortly for that. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:26 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi Gyorgy, Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file? Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more. Regards Stanislav -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Tuesday, April 16, 2019 2:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [EXT] TF-M Digest, Vol 6, Issue 12 WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. FW: Trusted boot - rollback protection (Tamas Ban) 2. TF-M ARM GCC Optimization issue (Stanislav Jancik) 3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Apr 2019 14:52:49 +0000 From: Tamas Ban <Tamas.Ban(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] FW: Trusted boot - rollback protection Message-ID: <AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. ------------------------------ Message: 2 Date: Tue, 16 Apr 2019 11:21:05 +0000 From: Stanislav Jancik <stanislav.jancik(a)nxp.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav ------------------------------ Message: 3 Date: Tue, 16 Apr 2019 11:58:29 +0000 From: Gyorgy Szing <Gyorgy.Szing(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Stanislav, Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 6, Issue 12 *********************************** -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TF-M ARM GCC Optimization issue

by Stanislav Jancik

Hi Gyorgy, Yes, it looks that this is the issue. I saw exactly this behavior when optimization was set to -O1. Do you think, that ARM will prepare official fix of this file? Moreover, when I tried to set optimization to -Os, the regression tests have stopped working at TFM_SST_TEST_1XXX test suite. But I did not try to find the reason why, therefore I cannot say more. Regards Stanislav -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of tf-m-request(a)lists.trustedfirmware.org Sent: Tuesday, April 16, 2019 2:00 PM To: tf-m(a)lists.trustedfirmware.org Subject: [EXT] TF-M Digest, Vol 6, Issue 12 WARNING: This email was created outside of NXP. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe. Send TF-M mailing list submissions to tf-m(a)lists.trustedfirmware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… or, via email, send a message with subject or body 'help' to tf-m-request(a)lists.trustedfirmware.org You can reach the person managing the list at tf-m-owner(a)lists.trustedfirmware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TF-M digest..." Today's Topics: 1. FW: Trusted boot - rollback protection (Tamas Ban) 2. TF-M ARM GCC Optimization issue (Stanislav Jancik) 3. Re: TF-M ARM GCC Optimization issue (Gyorgy Szing) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Apr 2019 14:52:49 +0000 From: Tamas Ban <Tamas.Ban(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] FW: Trusted boot - rollback protection Message-ID: <AM6PR08MB3126592CF647127402DB91C4E22B0(a)AM6PR08MB3126.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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. ------------------------------ Message: 2 Date: Tue, 16 Apr 2019 11:21:05 +0000 From: Stanislav Jancik <stanislav.jancik(a)nxp.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VI1PR04MB63200EB729C45B420D211A2890240(a)VI1PR04MB6320.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav ------------------------------ Message: 3 Date: Tue, 16 Apr 2019 11:58:29 +0000 From: Gyorgy Szing <Gyorgy.Szing(a)arm.com> To: "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M ARM GCC Optimization issue Message-ID: <VE1PR08MB4928420C61B16FA35C6F9A4D91240(a)VE1PR08MB4928.eurprd08.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Stanislav, Can you please check if the issue described here https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ Subject: Digest Footer TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… ------------------------------ End of TF-M Digest, Vol 6, Issue 12 ***********************************

6 years, 6 months

1
0
0 0

Re: [TF-M] TF-M ARM GCC Optimization issue

by Gyorgy Szing

Hi Stanislav, Can you please check if the issue described here https://developer.trustedfirmware.org/T234 is the same as you are reporting? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M Sent: 16 April 2019 13:21 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M ARM GCC Optimization issue Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

TF-M ARM GCC Optimization issue

by Stanislav Jancik

Hi, I am currently working on porting TF-M to our (NXP's) LPC55S69 platform. We have supported armclang compiler and we work on support of armgcc compiler. I found out, that the TF-M is working correctly only with optimization -O0 for secure code. I use "7 2018-q2-update" compiler. For example, when optimization -O1 is set for secure code, the regression tests are running correctly until TFM_IPC_TEST_1XXX test suite. When I debugged this issue, I found out that function and arguments are not properly assigned in function tfm_core_ns_ipc_request (tfm_psa_api_client.c). When I updated this function so the variables int32_t args[4]; struct tfm_sfn_req_s desc, *desc_ptr = &desc; and nt32_t res; were global instead of local. The tests have started running correctly. I so similar issue, when optimization was -Os, but only secure test suites run correctly in this case. I did not see such a behavior when I used armclang compiler. Did you try to use different optimization at Musca boards as well? Regards Stanislav

6 years, 6 months

1
0
0 0

FW: Trusted boot - rollback protection

by Tamas Ban

Actually the design doc propose to use a distinct security counter from image version (ih_ver in header). But in the most simple case this security counter can be derived from the image version, to have the exact same value (ignoring the build number). The image signature cover these continues blocks in memory: - image header - image - some part of TLV section (currently not covered, but due to multi image support it is planned to introduce a signed TLV section) Because these are contiguous regions in the memory it is not possible to place only the (header + TLV section) to the trusted memory but miss out the image itself (at least I cannot see how to solve) Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 08 April 2019 16:20 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Trusted boot - rollback protection For the platform without hardware for NV counter, but having trusted memory It is mentioned that the support is possible as follow : "an active image and related manifest data is stored in trusted memory then the included security counter cannot be compromised." the impact for this implementation in mcu-boot is limited to : * The test of the version (security counter is ih_ver from mcuboot header) * The placement of active image and related manifest data in a trusted memory. Is my understanding correct ? As the placement of full image in a trusted memory is a constraint. Can we limit the information placed in a trusted memory to : * image header, * TLV sections. This seems sufficient to support anti roll back. Of course additional impact on mcu-boot must be planned but as multi image support is also targeted , the placement of all images in a trusted memory is likely to be unachievable for all configurations. -- 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, 6 months

1
0
0 0

Re: [TF-M] Platform: Create platform service for pin functions

by Miklos Balint

Michel, I agree there is a need for a more generic design pattern for such platform-specific features. I think that there should be a single entry point for any platform specific service request to the platform/ directory and each platform should/could list the specific features it supports. Then the specific function type would be encoded in an invec to the service request. But I think a more detailed design proposal is needed with enough room for discussion before committing to a new pattern, and I'd prefer to avoid introducing platform dependencies in the services/ folder. That folder should ideally just have an indirection across HAL to a platform-specific service request arbiter. Any opinions or should I produce a more detailed proposal to show what I mean? Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: 11 April 2019 13:57 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Platform: Create platform service for pin functions I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

2
1
0 0

Re: [TF-M] Platform: Create platform service for pin functions

by Michel JAOUEN

I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/ On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis. As example , I post https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/ Best regards From: Michel JAOUEN Sent: mercredi 10 avril 2019 13:05 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Platform: Create platform service for pin functions Hello, I noticed the merge of this api, which seems require only for platform Musca_a. This create the need to implement dummy functions for the other platform. would it be better to make this configurable for each platform ? I think for the interface connected to platform partition, it is important to have a flexibility. As example some platform , may require an API requesting a pin to be configureable from non secure . Best regards

6 years, 6 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Ken Liu (Arm Technology China)

Hi Both, The intention of doing this is for packing parameters while handling non-secure psa_call(). This function has five parameters, which means the 5th one needs to be put in NS stack. If we extract 5th parameter in veneer function we need to enable non-secure memory accessing for veneer and implement some assembler code there to fetch PSP_NS. To make it simple at first stage we just pack 'psa_invec' and 'psa_outvec' as two inputs of tfm_psa_call_veneer(); that why the two types are invec -- because they really are inputs. This part really causes confuse and need to be discussed if we need to implement more proper way for this. Let's track it in the ticket. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Thursday, April 11, 2019 6:31 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > Hi Alan, > > I think you're right, the prototypes of these functions should be fixed. Moreover, > I think psa_outvec *out_vecs should drop the const qualifier to match > psa_call(...) prototypes, as it's an output parameter and needs to be non-const. > I have raised https://developer.trustedfirmware.org/T313 to keep track of this. > > Thanks, > Antonio > > ________________________________ > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, > Alan via TF-M <tf-m(a)lists.trustedfirmware.org> > Sent: 10 April 2019 22:12 > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? > > It seems to me that the 'psa_invec' type is incorrectly being used where the > 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. > > > > In tfm_api.h, I think this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs); > > > > should be this: > > > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs); > > > > > > And, in the implementation of the tfm_psa_call_veneer > > within tfm_psa_api_client.c, I think this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_invec *out_vecs) > > > > should be this: > > > > __tfm_secure_gateway_attributes__ > > psa_status_t tfm_psa_call_veneer(psa_handle_t handle, > > const psa_invec *in_vecs, > > const psa_outvec *out_vecs) > > > > > > And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: > > > > psa_invec in_vecs, out_vecs; > > > > should be this: > > > > psa_invec in_vecs; > > psa_outvec out_vecs; > > > > > > 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, 6 months

1
0
0 0

Re: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer?

by Antonio De Angelis

Hi Alan, I think you're right, the prototypes of these functions should be fixed. Moreover, I think psa_outvec *out_vecs should drop the const qualifier to match psa_call(...) prototypes, as it's an output parameter and needs to be non-const. I have raised https://developer.trustedfirmware.org/T313 to keep track of this. Thanks, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 10 April 2019 22:12 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] psa_invec type mismatch in tfm_psa_call_veneer? It seems to me that the 'psa_invec' type is incorrectly being used where the 'psa_outvec' type should be used everywhere tfm_psa_call_veneer() is used. In tfm_api.h, I think this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs); should be this: psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs); And, in the implementation of the tfm_psa_call_veneer within tfm_psa_api_client.c, I think this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_invec *out_vecs) should be this: __tfm_secure_gateway_attributes__ psa_status_t tfm_psa_call_veneer(psa_handle_t handle, const psa_invec *in_vecs, const psa_outvec *out_vecs) And, in the NS implementation of psa_call() within tfm_psa_ns_api.c, I think this: psa_invec in_vecs, out_vecs; should be this: psa_invec in_vecs; psa_outvec out_vecs; Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 6 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M