Hi Sebastian,
Want to know the scene when the secure fault:
* Are you saying that after couple of rounds of tests a secure fault would occur? * It happens on a specific version, but not the release and the latest master?
There is one race condition problem under debugging for dual-core based platforms, and it looks not the case you are testing.
Created task if you want to paste some debug code and data: https://developer.trustedfirmware.org/T975
Thanks.
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Sebastian Bøe via TF-M Sent: Thursday, November 11, 2021 5:56 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] race condition in IPC
Hi,
are there any known race conditions in IPC/PS that affect TF-M 1.4-ish?
More specifically TF-M revision a199c3047f320a2f82b9a0c27af5b50991184e0f, which is 38 commits prior to TF-Mv1.4.0-RC1.
I am observing that adding printfs, or otherwise changing the flash alignment and therefore runtime of my code will affect whether the PS reliability test suite passes or not.
More specifically, if it triggers a secure fault after x iterations of 2001, or y iterations of 2002, etc. depending on where I put my printfs or otherwise affect the alignment of the code.
This is run on the nrf platform as a part of the nrf SDK.
Test Suite PS reliability tests (TFM_PS_TEST_2XXX)... 'repetitive sets and gets in/from an asset' 'repetitive sets, gets and removes'
It does not reproduce under GDB and I am unable to unwind the backtrace from the secure fault handler. Any tips about recovering a backtrace from a secure fault handler would also be appreciated.
#0 SecureFault_Handler () at /home/sebo/ncs/modules/tee/tfm/trusted-firmware-m/secure_fw/spm/cmsis_psa/arch/tfm_arch_v8m_main.c:96 #1 0xffffffb4 in ?? ()
I have not been able to reproduce it in the latest upstream TF-M release/revision, but that could just be because I haven't been able to hit the race condition.
Sebastian Bøe