Hi Thomas,
Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs.
Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different.
Kind regards, Jamie
From: Thomas Törnblom thomas.tornblom@iar.com Sent: 02 December 2019 22:50 To: Jamie Fox Jamie.Fox@arm.com; Minos Galanakis Minos.Galanakis@arm.com Cc: nd nd@arm.com Subject: Re: [TF-M] Regression test issues with IAR port
Hi Jamie,
From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA;
status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; }
/* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test.
Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain:
sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy()
As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related.
sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req()
I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get().
It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020.
I'll continue debugging this...
Cheers, Thomas
Den 2019-11-28 kl. 17:37, skrev Jamie Fox:
Hi Thomas,
We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think.
Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping.
The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread.
Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there?
Kind regards,
Jamie
-----Original Message-----
From: TF-M tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M
Sent: 28 November 2019 15:45
To: Minos Galanakis Minos.Galanakis@arm.commailto:Minos.Galanakis@arm.com; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
Cc: nd nd@arm.commailto:nd@arm.com
Subject: Re: [TF-M] Regression test issues with IAR port
Sorry, I was being unclear.
I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread.
The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there.
Cheers,
Thomas
Den 2019-11-28 kl. 16:00, skrev Minos Galanakis:
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure
suite.
For SST The logic is located at :
* Non Secure side tests:
test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests:
test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
----------------------------------------------------------------------
--
*From:* TF-M tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org on behalf of
Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
*Sent:* 28 November 2019 14:49
*To:* tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
*Subject:* [TF-M] Regression test issues with IAR port In my quest to
port TF-M to the IAR toolchain I've run into issues with a few of the
tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con
figs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com mailto:thomas.tornblom@iar.commailto:thomas.tornblom@iar.com
Website: www.iar.comhttp://www.iar.com http://www.iar.comhttp://www.iar.com http://www.iar.comhttp://www.iar.com
Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
http://www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
http://www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
--
TF-M mailing list
TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
For the three 1018 tests, tfm_core_get_caller_client_id() does indeed return the same client_id, -1 with the IAR build.
Comparing this with the ARMCLANG build I see that that returns -20 for the call for 1018 task_2.
Thomas
Den 2019-12-03 kl. 04:20, skrev Jamie Fox:
Hi Thomas,
Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs.
Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different.
Kind regards,
Jamie
*From:*Thomas Törnblom thomas.tornblom@iar.com *Sent:* 02 December 2019 22:50 *To:* Jamie Fox Jamie.Fox@arm.com; Minos Galanakis Minos.Galanakis@arm.com *Cc:* nd nd@arm.com *Subject:* Re: [TF-M] Regression test issues with IAR port
Hi Jamie,
From tfm_sst_test_1018_task_2():
... uint8_t read_data[] = READ_DATA;
status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; }
/* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ...
The call to psa_ps_get() returns 0, which is a failure in this test.
Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain:
sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy()
As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related.
sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req()
I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get().
It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020.
I'll continue debugging this...
Cheers, Thomas
Den 2019-11-28 kl. 17:37, skrev Jamie Fox:
Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M<tf-m-bounces@lists.trustedfirmware.org> <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis<Minos.Galanakis@arm.com> <mailto:Minos.Galanakis@arm.com>;tf-m@lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Cc: nd<nd@arm.com> <mailto:nd@arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M<tf-m-bounces@lists.trustedfirmware.org> <mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org> <mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:*tf-m@lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> <tf-m@lists.trustedfirmware.org> <mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com <mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com> Website:www.iar.com <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> Twitter:www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M@lists.trustedfirmware.org <mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m--
*Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com mailto:thomas.tornblom@iar.comWebsite: www.iar.com http://www.iar.com Twitter: www.twitter.com/iarsystems http://www.twitter.com/iarsystems
So seems that the NS client IDs are not getting populated correctly when built with IAR. -1 is the default for NS clients.
The doc in docs/user_guides/tfm_ns_client_identification.rst describes how the NS client IDs are managed.
Probably you will have to do some debugging in secure_fw/core/tfm_nspm_func.c to compare the behaviour with the Armclang and IAR builds. The “TZ_” functions in that file should be called by the NS RTOS when a new NS context is created or switched to (i.e. for each SST NS test thread).
Jamie
From: Thomas Törnblom thomas.tornblom@iar.com Sent: 05 December 2019 00:06 To: Jamie Fox Jamie.Fox@arm.com; Minos Galanakis Minos.Galanakis@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Regression test issues with IAR port
For the three 1018 tests, tfm_core_get_caller_client_id() does indeed return the same client_id, -1 with the IAR build.
Comparing this with the ARMCLANG build I see that that returns -20 for the call for 1018 task_2.
Thomas Den 2019-12-03 kl. 04:20, skrev Jamie Fox: Hi Thomas,
Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs.
Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different.
Kind regards, Jamie
From: Thomas Törnblom thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Sent: 02 December 2019 22:50 To: Jamie Fox Jamie.Fox@arm.commailto:Jamie.Fox@arm.com; Minos Galanakis Minos.Galanakis@arm.commailto:Minos.Galanakis@arm.com Cc: nd nd@arm.commailto:nd@arm.com Subject: Re: [TF-M] Regression test issues with IAR port
Hi Jamie,
From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA;
status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; }
/* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test.
Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain:
sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy()
As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related.
sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req()
I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get().
It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020.
I'll continue debugging this...
Cheers, Thomas
Den 2019-11-28 kl. 17:37, skrev Jamie Fox:
Hi Thomas,
We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think.
Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping.
The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread.
Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there?
Kind regards,
Jamie
-----Original Message-----
From: TF-M tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org On Behalf Of Thomas Törnblom via TF-M
Sent: 28 November 2019 15:45
To: Minos Galanakis Minos.Galanakis@arm.commailto:Minos.Galanakis@arm.com; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
Cc: nd nd@arm.commailto:nd@arm.com
Subject: Re: [TF-M] Regression test issues with IAR port
Sorry, I was being unclear.
I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread.
The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there.
Cheers,
Thomas
Den 2019-11-28 kl. 16:00, skrev Minos Galanakis:
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure
suite.
For SST The logic is located at :
* Non Secure side tests:
test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests:
test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
----------------------------------------------------------------------
--
*From:* TF-M tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org on behalf of
Thomas Törnblom via TF-M tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
*Sent:* 28 November 2019 14:49
*To:* tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org
*Subject:* [TF-M] Regression test issues with IAR port In my quest to
port TF-M to the IAR toolchain I've run into issues with a few of the
tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con
figs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n
on_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com mailto:thomas.tornblom@iar.commailto:thomas.tornblom@iar.com
Website: www.iar.comhttp://www.iar.com http://www.iar.comhttp://www.iar.com http://www.iar.comhttp://www.iar.com
Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
http://www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
http://www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
--
TF-M mailing list
TF-M@lists.trustedfirmware.orgmailto:TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
--
Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.commailto:thomas.tornblom@iar.com Website: www.iar.comhttp://www.iar.com Twitter: www.twitter.com/iarsystemshttp://www.twitter.com/iarsystems
Thanks Jamie,
Problem solved!
Turned out the IAR build of the non-secure RTX library was incorrectly built as a secure library, which caused the TZ_LoadContext_S to never be called.
So now I need to head over to the CMSIS_5 repo and rebuild that :)
Cheers, Thomas
Den 2019-12-05 kl. 08:12, skrev Jamie Fox:
So seems that the NS client IDs are not getting populated correctly when built with IAR. -1 is the default for NS clients.
The doc in docs/user_guides/tfm_ns_client_identification.rst describes how the NS client IDs are managed.
Probably you will have to do some debugging in secure_fw/core/tfm_nspm_func.c to compare the behaviour with the Armclang and IAR builds. The “TZ_” functions in that file should be called by the NS RTOS when a new NS context is created or switched to (i.e. for each SST NS test thread).
Jamie
*From:*Thomas Törnblom thomas.tornblom@iar.com *Sent:* 05 December 2019 00:06 *To:* Jamie Fox Jamie.Fox@arm.com; Minos Galanakis Minos.Galanakis@arm.com; tf-m@lists.trustedfirmware.org *Cc:* nd nd@arm.com *Subject:* Re: [TF-M] Regression test issues with IAR port
For the three 1018 tests, tfm_core_get_caller_client_id() does indeed return the same client_id, -1 with the IAR build.
Comparing this with the ARMCLANG build I see that that returns -20 for the call for 1018 task_2.
Thomas
Den 2019-12-03 kl. 04:20, skrev Jamie Fox:
Hi Thomas, Looks to me like the call to psa_ps_get() is retrieving the data set by psa_ps_set() in tfm_sst_test_1018_task_1(). This shouldn’t happen, because the two task functions are run in two different threads, which should have different client IDs. Can you check the client ID returned by tfm_core_get_caller_client_id() in tfm_sst_set_req() and tfm_sst_get_req() in each case? They should be different. Kind regards, Jamie *From:*Thomas Törnblom <thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com> *Sent:* 02 December 2019 22:50 *To:* Jamie Fox <Jamie.Fox@arm.com> <mailto:Jamie.Fox@arm.com>; Minos Galanakis <Minos.Galanakis@arm.com> <mailto:Minos.Galanakis@arm.com> *Cc:* nd <nd@arm.com> <mailto:nd@arm.com> *Subject:* Re: [TF-M] Regression test issues with IAR port Hi Jamie, From tfm_sst_test_1018_task_2(): --- ... uint8_t read_data[] = READ_DATA; status = psa_ps_get(uid, offset, data_len, read_data); if (status != PSA_PS_ERROR_UID_NOT_FOUND) { TEST_FAIL("Get should not succeed with invalid thread name"); return; } /* Check that read data has not been modified */ if (memcmp(read_data, READ_DATA, sizeof(read_data)) != 0) { TEST_FAIL("Read data should not have changed"); return; } ... --- The call to psa_ps_get() returns 0, which is a failure in this test. Out of curiosity I stopped right after this call and I notice that the read_data array had been clobbered and now starts with the string "THEQUICKBROWNFOX". This appears to happen in the following call chain: sst_object_read() -> sst_req_mngr_write_asset_data() -> memcpy() As there is a test that the data has not been clobbered after the return, I suspect that the two issues are related. sst_req_mngr_write_asset_data() uses a global variable p_data as the destination for the memcpy() call, and this variable gets set in the call chain tfm_core_sfn_request() -> tfm_sst_get_req() I see that the "info" argument in tfm_sst_test_1019_task_2() is also clobbered after the call to psa_ps_get(). It appears that it is only the tests with invalid thread names that fails, 1018, 1019 and 1020. I'll continue debugging this... Cheers, Thomas Den 2019-11-28 kl. 17:37, skrev Jamie Fox: Hi Thomas, We use prebuilt RTX binaries from the CMSIS_5 repo, which does make debugging RTX code more difficult. Before we go down that route, it's worth checking that the error isn't in TF-M I think. Just looking at the errors you are getting, the most likely explanation to me is that something has gone wrong with registering the mapping from RTX thread name to NS client ID. Your first failure is on line 936 of test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c for example, which checks that one thread cannot access the uid belonging to a different thread. This could happen, for example, if the two threads ended up with the same client_id due to some error in the mapping. The mapping is done by tfm_nspm_register_client_id() in interface/src/tfm_nspm_api.c, which is called by test_task_runner() in test/suites/sst/non_secure/ns_test_helpers.c at the start of the execution of each SST test thread. Could you check that tfm_nspm_register_client_id() is getting the correct client ID for each test thread? Also, it calls a function with the " __attribute__ ((naked))" attribute. As this is a compiler extension could there be some problem there? Kind regards, Jamie -----Original Message----- From: TF-M<tf-m-bounces@lists.trustedfirmware.org> <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 November 2019 15:45 To: Minos Galanakis<Minos.Galanakis@arm.com> <mailto:Minos.Galanakis@arm.com>;tf-m@lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> Cc: nd<nd@arm.com> <mailto:nd@arm.com> Subject: Re: [TF-M] Regression test issues with IAR port Sorry, I was being unclear. I know where the tests start and ends, but the work appears to be handed off to the OS so that I can't (easily) step through the code and find what function is being used to look up the thread. The call to psa_ps_get() is used by the test and I assume it ends up using an RTX call and I would like to check what happens there. Cheers, Thomas Den 2019-11-28 kl. 16:00, skrev Minos Galanakis: Thomas, Tests are placed under the test -> suites -> service name directory. In your case you are looking at the Secure Storage Service non secure suite. For SST The logic is located at : * Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c * Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c Hope that helps Minos ---------------------------------------------------------------------- -- *From:* TF-M<tf-m-bounces@lists.trustedfirmware.org> <mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m@lists.trustedfirmware.org> <mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:*tf-m@lists.trustedfirmware.org <mailto:tf-m@lists.trustedfirmware.org> <tf-m@lists.trustedfirmware.org> <mailto:tf-m@lists.trustedfirmware.org> *Subject:* [TF-M] Regression test issues with IAR port In my quest to port TF-M to the IAR toolchain I've run into issues with a few of the tests, and I need some hints where to look. The cmake build command line: --- cmake .. -G"Unix Makefiles" -DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\con figs\ConfigRegression.cmake -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM -DCMAKE_BUILD_TYPE=RelWithDebInfo --- This results in three similar tests that fails: --- > Executing 'TFM_SST_TEST_1018' Description: 'Get interface with invalid thread name' Get should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:936) TEST FAILED! > Executing 'TFM_SST_TEST_1019' Description: 'Get info interface with invalid thread name' Get info should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1015) TEST FAILED! > Executing 'TFM_SST_TEST_1020' Description: 'Remove interface with invalid thread name' Remove should not succeed with invalid thread name (Failed at C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/n on_secure/psa_ps_ns_interface_testsuite.c:1093) TEST FAILED! --- Where do I find the logic that determines if these tests succeed or fails? Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com <mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com> <mailto:thomas.tornblom@iar.com> Website:www.iar.com <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> <http://www.iar.com> Twitter:www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M@lists.trustedfirmware.org <mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com <mailto:thomas.tornblom@iar.com>Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>--
*Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom@iar.com mailto:thomas.tornblom@iar.comWebsite: www.iar.com http://www.iar.com Twitter: www.twitter.com/iarsystems http://www.twitter.com/iarsystems
tf-m@lists.trustedfirmware.org
-
Jamie Fox -
Thomas Törnblom