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@nxp.com Sent: Wednesday, April 24, 2019 3:35 PM To: Ken Liu (Arm Technology China) Ken.Liu@arm.com Cc: TF-M@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_requ 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@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@lists.trustedfirmware.org Cc: nd nd@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%2Fdevelope 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%2Freview.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@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@lists.trustedfirmware.org; nd nd@arm.com Cc: nd nd@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@lists.trustedfirmware.org on behalf of Antonio De Angelis via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, April 23, 2019 9:58 PM To: tf-m@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%2Fdevelope 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@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@arm.com Cc: TF-M@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@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@lists.trustedfirmware.org Cc: nd nd@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@lists.trustedfirmware.org on behalf of Andrej Butok via TF-M tf-m@lists.trustedfirmware.org Sent: Tuesday, April 23, 2019 9:16 PM To: Antonio De Angelis Cc: TF-M@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@lists.trustedfirmware.org On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, April 23, 2019 3:02 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@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@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 23 April 2019 13:19 To: Andrej Butok andrey.butok@nxp.com Cc: TF-M@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@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: Tuesday, April 23, 2019 1:38 PM To: TF-M@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@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@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@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@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@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@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%7C686ea1 d3bc2
b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 4%2BC
zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0
TF-M mailing list TF-M@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%7C686ea1 d3bc2
b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 4%2BC
zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0
TF-M mailing list TF-M@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%7C686ea1 d3bc2
b4c6fa92cd99c5c301635%7C0%7C0%7C636916861232924039&sdata=i4R0 4%2BC
zqYsB2bIBHHVUI1aOMNSEVKJa17ABl1vamUM%3D&reserved=0
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus... 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