- TF-M - lists.trustedfirmware.org

by Miklos Balint

Hi Thomas, I see no major issue with either suggestion, I think it makes sense to introduce improvements in these matters. For issue #1 it makes very much sense to have a shared header file for all components that rely on these definitions. I don't recall any reason why that should not be possible, it's simply something that hasn't been done due to limited bandwidth for such clean-up of the code. For issue #2 we have had some internal discussions on the best way to handle compiler dependencies, and the suggestion I liked the most is similar to your suggestion below, but instead of having a single header file, having a compiler folder with each supported toolchain as a separate sub-folder, each defining their own version of tfm_compiler.h to provide the definitions required by TF-M. The compiler-specific cmake file can then simply point to the appropriate location for the compiler-specific inclusion, avoiding compiler-specific ifdef:s. Let me know your thoughts on this approach Thanks and kindest regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 13 June 2019 16:11 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Feature request While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Antonio De Angelis

Hi Andrej, Does this affect also any of the reference platforms (i.e. AN521)? If the same behaviour appears on a reference platform, it will suggest that is likely not related to platform code. It would be good if you can identify the EXACT commit that is giving you this problem, as we can't reproduce, so that we can have a look in detail to the source code. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 14 June 2019 16:12 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Is TFM_PSA_API broken? Just FYI: Downgraded to commit SHA-1: 25e2b2dba5d7eb3ba0da14384a6c8240278f5c15 (Crypto: Implement additional PSA Crypto APIs). It becomes much better, but finally goes to the assert in some time (tfm_thrd_context_switch:170). Will continue next week. The terminal log: Sec Thread] Secure image initializing! [Sec Thread] hello! this is ipc client test sp! [Sec Thread] Connect success! [Sec Thread] Call success! #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' TEST PASSED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' TEST PASSED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2004' Description: 'Set interface with invalid data length' TEST PASSED! > Executing 'TFM_SST_TEST_2005' Description: 'Set interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2006' Description: 'Get interface with valid data' TEST PASSED! > Executing 'TFM_SST_TEST_2007' Description: 'Get interface with zero data length' TEST PASSED! > Executing 'TFM_SST_TEST_2008' Description: 'Get interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2009' Description: 'Get interface with invalid data lengths and offsets' TEST PASSED! > Executing 'TFM_SST_TEST_2010' Description: 'Get interface with NULL data pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2011' Description: 'Get info interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2012' Description: 'Get info interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2013' Description: 'Get info interface with invalid UIDs' TEST PASSED! > Executing 'TFM_SST_TEST_2014' Description: 'Get info interface with NULL info pointer' TEST PASSED! > Executing 'TFM_SST_TEST_2015' Description: 'Remove interface with valid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2016' Description: 'Remove interface with write once UID' TEST PASSED! > Executing 'TFM_SST_TEST_2017' Description: 'Remove interface with invalid UID' TEST PASSED! > Executing 'TFM_SST_TEST_2018' Description: 'Block compaction after remove' TEST PASSED! > Executing 'TFM_SST_TEST_2019' Description: 'Multiple partial gets' TEST PASSED! > Executing 'TFM_SST_TEST_2020' Description: 'Multiple sets to same UID from same thread' TEST PASSED! > Executing 'TFM_SST_TEST_2021' Description: 'Get support interface' TEST PASSED! TESTSUITE PASSED! Running Test Suite SST reliability tests (TFM_SST_TEST_3XXX)... > Executing 'TFM_SST_TEST_3001' Description: 'repetitive sets and gets in/from an asset' > Iteration 15 of 15 TEST PASSED! > Executing 'TFM_SST_TEST_3002' Description: 'repetitive sets, gets and removes' > Iteration 15 of 15 TEST PASSED! TESTSUITE PASSED! Running Test Suite Crypto secure interface tests (TFM_CRYPTO_TEST_5XXX)... > Executing 'TFM_CRYPTO_TEST_5001' Description: 'Secure Key management interface' Assert:tfm_thrd_context_switch:170 From: Andrej Butok Sent: Friday, June 14, 2019 4:14 PM To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, > Please check your modification in SST partition No modifications from my side. As it becomes wasting of time, a debugging is not consistent and looks like uninitialized variable, stack or something else. I have decided to find a TFM commit which caused this abnormal behavior. So far, it occurs in a commit between: NOT WORKING: SHA-1: 122360ffb1e7278406183714249afefcb2184488 * Attest: Replace example asymmetric key-pair WORKING: SHA-1: 4743e6731b0fe8a00ceebfd74da098c7676ac6e0 * Crypto: Add IPC compatibility Thanks, Andrej From: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Sent: Friday, June 14, 2019 4:00 PM To: Andrej Butok <mailto:andrey.butok@nxp.com> Cc: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: Re: Is TFM_PSA_API broken? Hi Andrej, As I said, that workaround only works for specified case. Debugging these failed cases with this patch applied will lead you into heavy core debugging. We need to find out the root cause, why the assert is triggered? There is no reason that all partitions go into block state, unless there are some improper modification in core or secure partitions. Please check your modification in SST partition, try to print something in your SST thread, to see why the thread keeps in block state. If a client calls psa_connect/psa_all, SPM would activate the partition into running state with function tfm_spm_send_event(). The correct call routine should be (psa_call has the similar routine): tfm_sst_test_2001->psa_connect->...->SVC_Handler->tfm_svcall_psa_connect->tfm_spm_send_event->....-> (your partition thread). Please remove the workaround patch, and try to debug to see if the call routine is correct. Thanks. -Ken ________________________________________ From: Andrej Butok <mailto:andrey.butok@nxp.com> Sent: Friday, June 14, 2019 8:13 PM To: Ken Liu (Arm Technology China) Cc: mailto:tf-m@lists.trustedfirmware.org Subject: RE: Is TFM_PSA_API broken? Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: mailto:TF-M@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <mailto:Antonio.DeAngelis@arm.com> > Cc: mailto:tf-m@lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf > Of Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: mailto:tf-m@lists.trustedfirmware.org > Cc: nd <mailto:nd@arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M > <mailto:tf-m-bounces@lists.trustedfirmware.org%3cmailto:tf-m-%0b> > mailto:bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok > via TF-M > > Sent: 13 June 2019 15:46 > > To: > mailto:tf-m@lists.trustedfirmware.org%3cmailto:tf-m@lists.trustedfirmw > are.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > mailto:TF-M@lists.trustedfirmware.org%3cmailto:TF-M@lists.trustedfirmw > are.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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > mailto: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%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%3D&reserved=0 -- TF-M mailing list mailto:TF-M@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, 9 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Hi Ken, Your patch/fix helped, so now there is no stuck in assert. But all regression tests are failed: #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Set should not fail with valid UID (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:153) TEST FAILED! > Executing 'TFM_SST_TEST_2002' Description: 'Set interface with create flags' Set should not fail with no flags (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:199) TEST FAILED! > Executing 'TFM_SST_TEST_2003' Description: 'Set interface with NULL data pointer' Set should succeed with NULL data pointer and zero length (Failed at ../../../../../../../middleware/tfm/test/suites/sst/secure/psa_ps_s_interface_testsuite.c:243) TEST FAILED! Will try to investigate... -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Friday, June 14, 2019 10:32 AM To: TF-M(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Andrej Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is > this correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function > API approach. > > Probably, something serious happened during last two weeks (before it > worked), may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Antonio De Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You > can see from existing IPC - specific build configurations which flags > need to be set to make sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M > > Sent: 13 June 2019 15:46 > > To: > tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API > (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred > from platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id > (referred from audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are > using the functions (printed in the log) which are not > available/disabled when TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto: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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto: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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%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%7C441c81dc90a44fb5418408d6f0a2b68a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636960978972859087&sdata=weHHf8wG3 > nlnTsI1JEA5Ww0D9sXSf4oJKyLkImmaCi8%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, 9 months

2
3
0 0

T398: Initial support for IAR Embedded Workbench for Arm tool chain

by Thomas Törnblom

I have just created T398 for integrating source cleanup to improve portability. I have just pushed a patch for review. /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 9 months

1
0
0 0

Re: [TF-M] Contribution guide, where?

by Kevin Townsend

Hi Thomas, It's a bit slim, but I assume you noticed this but are looking for further details? https://git.trustedfirmware.org/trusted-firmware-m.git/tree/contributing.rst Best regards, Kevin On Fri, 14 Jun 2019 at 13:10, Thomas Törnblom via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > I'm about to submit a set of cleanup patches but have not been able to > find the contribution guide. > > Most of the useful documentation I've found seems to be related to TF-A. > > So where is it? > > /Thomas > > -- > > *Thomas Törnblom*, /Product Engineer/ > IAR Systems AB > Box 23051, Strandbodgatan 1 > SE-750 23 Uppsala, SWEDEN > Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 > E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> > Website: www.iar.com <http://www.iar.com> > Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 9 months

1
0
0 0

Contribution guide, where?

by Thomas Törnblom

I'm about to submit a set of cleanup patches but have not been able to find the contribution guide. Most of the useful documentation I've found seems to be related to TF-A. So where is it? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 9 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Ken Liu (Arm Technology China)

Hi Andrej, tfm_thrd_context_switch() does not want to thread to be running is NULL. And actually it should never happen in existing implement unless IRQ is involved. Here is a patch for fixing this, but I am not sure if you are under the same case we met: https://review.trustedfirmware.org/c/trusted-firmware-m/+/959 I am curious about your environment, at least one partition will be running in latest master branch. Can you share me your changes? Are your using original TF-M and which configuration file you are using? Thanks. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej > Butok via TF-M > Sent: Friday, June 14, 2019 4:15 PM > To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > Hi Antonio, > > > > So, I have disabled Platform and Log services. > > Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is this > correct? > > After that it becomes compliable. > > > > But when starting the regression tests, I am getting assert in > tfm_thrd_conext_switch(). Terminal log: > > > > [Sec Thread] Secure image initializing! > > > > NS code is running... > > > > #### Execute test suites for the Secure area #### > > Running Test Suite PSA protected storage S interface tests > (TFM_SST_TEST_2XXX)... > > > Executing 'TFM_SST_TEST_2001' > > Description: 'Set interface' > > Assert:tfm_thrd_context_switch:170 > > > > So I am stuck now, and no matter what to use the IPC or the Function API > approach. > > Probably, something serious happened during last two weeks (before it worked), > may be in platform dependent code. > > NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). > > > > Any tips? > > > > Thanks, > > Andrej > > > > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De > Angelis via TF-M > Sent: Thursday, June 13, 2019 5:00 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: Re: [TF-M] Is TFM_PSA_API broken? > > > > Hi Andrej, > > > > "Should the Log and Platform services be disabled for IPC?" > > > > Yes, platform service and Audit Log service do not support IPC. You can see from > existing IPC - specific build configurations which flags need to be set to make > sure these two services are not built when IPC builds are selected. > > > > Thanks, > > Antonio > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m- > bounces(a)lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M > > Sent: 13 June 2019 15:46 > > To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> > > Subject: [TF-M] Is TFM_PSA_API broken? > > > > Hello, > > > > I use absolutely the latest TF-M (SHA-1: > 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) > > > > I am trying to run the regression-test application using IPC API (TFM_PSA_API is > defined) The application is compliable with errors: > > Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from > platform_sp.o). > > Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from > audit_core.o). > > Not enough information to list image symbols. > > > > It is caused by the fact that the platform and audit log services are using the > functions (printed in the log) which are not available/disabled when > TFM_PSA_API is defined. > > Is it known issue? > > Any suggestions? > > Should the Log and Platform services be disabled for IPC? > > > > Thanks, > > Andrej > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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%7C4416c02536e54d420 > bdc08d6f00fc1ff%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6369 > 60347799555976&sdata=1zhWkIyBjqiiTqtf0tYdtxRACLofQ%2B5Po6tC3cqW > Fis%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Andrej Butok

Hi Antonio, So, I have disabled Platform and Log services. Also, TFM_NS_CLIENT_IDENTIFICATION have to be undefined for IPC. Is this correct? After that it becomes compliable. But when starting the regression tests, I am getting assert in tfm_thrd_conext_switch(). Terminal log: [Sec Thread] Secure image initializing! NS code is running... #### Execute test suites for the Secure area #### Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)... > Executing 'TFM_SST_TEST_2001' Description: 'Set interface' Assert:tfm_thrd_context_switch:170 So I am stuck now, and no matter what to use the IPC or the Function API approach. Probably, something serious happened during last two weeks (before it worked), may be in platform dependent code. NOTE: I am using a different platform LPC55S69 and IDE approach (not cmake). Any tips? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, June 13, 2019 5:00 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is TFM_PSA_API broken? Hi Andrej, "Should the Log and Platform services be disabled for IPC?" Yes, platform service and Audit Log service do not support IPC. You can see from existing IPC - specific build configurations which flags need to be set to make sure these two services are not built when IPC builds are selected. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M Sent: 13 June 2019 15:46 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is TFM_PSA_API broken? Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@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<mailto:TF-M@lists.trustedfirmware.org> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 9 months

1
0
0 0

Re: [TF-M] Is TFM_PSA_API broken?

by Antonio De Angelis

Hi Andrej, "Should the Log and Platform services be disabled for IPC?" Yes, platform service and Audit Log service do not support IPC. You can see from existing IPC - specific build configurations which flags need to be set to make sure these two services are not built when IPC builds are selected. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 13 June 2019 15:46 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Is TFM_PSA_API broken? Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Is TFM_PSA_API broken?

by Andrej Butok

Hello, I use absolutely the latest TF-M (SHA-1: 81fb08cd66c1037a5e6c57e46ad5946bfc8a0d0e) I am trying to run the regression-test application using IPC API (TFM_PSA_API is defined) The application is compliable with errors: Error: L6218E: Undefined symbol tfm_spm_request_reset_vote (referred from platform_sp.o). Error: L6218E: Undefined symbol tfm_core_get_caller_client_id (referred from audit_core.o). Not enough information to list image symbols. It is caused by the fact that the platform and audit log services are using the functions (printed in the log) which are not available/disabled when TFM_PSA_API is defined. Is it known issue? Any suggestions? Should the Log and Platform services be disabled for IPC? Thanks, Andrej

6 years, 9 months

1
0
0 0

Feature request

by Thomas Törnblom

While working on porting TF-M to the IAR toolchain, I've run into a couple of issues I'd like to discuss. 1) The duplicated REGION/REGION_NAME/REGION_DECLARE macros. Why are these not defined in an include file instead of being defined in eight different c files? I see that they are also defined in spm_db.h, but that is only included in spm related files. 2) I suggest adding a toolchain related include file that should be included in every source file that is part of TF-M. This could be something similar to cmsis_compiler.h, where a toolchain vendor could add stuff that only relates to a specific toolchain. In our case that could include things like: --- #ifdef __ICCARM__ #define $$ZI$$Limit $$Limit #define $$ZI$$Base $$Base #define Image$$ #endif --- Ideas? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 9 months

1
0
0 0

[RFC] Move configuration files into specified directory

by Ken Liu (Arm Technology China)

Hi, Since the number of configuration files is increasing, let’s move the configuration files (ConfigXXXX.cmake) into specified directory. This would reduces the files under root directory and makes the structure more clearer. I have created the issue and patch for it: https://developer.trustedfirmware.org/T394 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1234 IMPORTANT NOTES: To be compatible with the existing building configurations, the existing configuration files have been forwarded into the corresponded configuration file under ./configs. Which means there are two set of configuration files under sources tree at current – but this will change soon. There is a warning while you are building with root configurations files: “Please use the configs available in the ./config sub-directory.” So please: - If you are planning to create new configuration, create it under ./configs instead of root directory - The reference of configuration files under root directory will be removed soon, please change your build system setting to reference the configuration files put under ./configs Any feedbacks please reply this mail or put comments under the issue, thanks 😉 -Ken

6 years, 9 months

1
0
0 0

PSA Developer API compliance tests

by Antonio De Angelis

Dear all, The new tag which has just been made available from the psa-arch-tests, available here: https://github.com/ARM-software/psa-arch-tests/releases/tag/v19.06_API0.9 is the one that has to be used to be able to verify PSA Developer API compliance with the latest TF-M. The procedure to follow to build and run the tests remains the same. Thanks, Antonio

6 years, 9 months

1
0
0 0

Supported versions of the Armclang compiler in the TF-M build

by Antonio De Angelis

Dear all, We are considering to drop support for older versions of the Armclang compiler (i.e. 6.7 and 6.9) to focus support on newer releases (thus increasing the requirement on Armclang version to 6.10 or higher). https://developer.trustedfirmware.org/T392 https://review.trustedfirmware.org/c/trusted-firmware-m/+/1223 If you have any specific requirement to use Armclang 6.7 or 6.9, please get in touch here or on the review. Thanks, Antonio

6 years, 9 months

1
0
0 0

Two changes merged by mistake

by Miklos Balint

Hi all, Two changes that have underwent multiple rounds of review and test were accidentally merged instead of being pushed for review and final approval. I was at fault, apologies for that. Additional tests of the changes flagged up no regression. Let me know if you have any concerns or questions, Thanks and regards Miklos

6 years, 9 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Please ping me when this tag will appear. Thank you, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Tuesday, May 28, 2019 2:19 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, please find my replies inline in red. ________________________________ 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: 28 May 2019 07:38 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. [Antonio] Not sure exactly what you mean here. This is the latest Crypto API header used in the development branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… And it uses handles instead of slots as I have explained earlier, handles being a newer concept. Also, please bear in mind that the PSA Crypto API development happens on this branch: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… , Mbed Crypto being a reference implementation of the API, which means that the API itself can have new concepts which are not part of the reference implementation yet. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. [Antonio] TF-M Crypto service is indeed aligned to latest available release of Mbed Crypto, which is Mbed Crypto 1.0.0 (dated 1st April 2019): https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… As soon as there will be new releases, TF-M Crypto will align to those. The TF-M Crypto service is not aligned to the development branch because, as mentioned, that branch undergoes active daily development and would be too difficult to track. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? [Antonio] The ew_beta0 branch was used as a temporary milestone which was using the old 0.1.0beta API. For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Best regards, Antonio Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? 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…

6 years, 9 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Antonio De Angelis

Hi Andrej, please find my replies inline in red. ________________________________ 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: 28 May 2019 07:38 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. [Antonio] Not sure exactly what you mean here. This is the latest Crypto API header used in the development branch: https://github.com/ARMmbed/mbed-crypto/blob/development/include/psa/crypto.h And it uses handles instead of slots as I have explained earlier, handles being a newer concept. Also, please bear in mind that the PSA Crypto API development happens on this branch: https://github.com/ARMmbed/mbed-crypto/tree/psa-api-1.0-beta , Mbed Crypto being a reference implementation of the API, which means that the API itself can have new concepts which are not part of the reference implementation yet. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. [Antonio] TF-M Crypto service is indeed aligned to latest available release of Mbed Crypto, which is Mbed Crypto 1.0.0 (dated 1st April 2019): https://github.com/ARMmbed/mbed-crypto/releases As soon as there will be new releases, TF-M Crypto will align to those. The TF-M Crypto service is not aligned to the development branch because, as mentioned, that branch undergoes active daily development and would be too difficult to track. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? [Antonio] The ew_beta0 branch was used as a temporary milestone which was using the old 0.1.0beta API. For the newer API version, the psa-arch-test team will provide a new tag on the master branch in the coming days (this is still not available yet). Best regards, Antonio Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? 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://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Andrej Butok

Hi Antonio, > TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 If to follow the latest development branch of Mbed-Crypto, actually it has started using of "handles" instead of "slots" (the obsolete version is using handles). So by using the old mbed-Crypto release, you have downgraded the Crypto API. Please use the latest available mbed-Crypto (do not afraid - it is functional, checked) and avoid this created mess and desynchronization between all PSA related projects. > The psa-arch-test team is in the process of providing an update on the master branch The master branch, as was declared by PSA Test Suite team, is not used for PSA Functional API certification. Instead, as was declared by PSA Test Suite team, it have to be used the ew_beta0 branch. Please clarify what PSA-TestSuite branch must be used with TFM now? Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Monday, May 27, 2019 6:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Old Mbed-Crypto library? Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co… -b mbedcrypto-1.0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? 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…

6 years, 9 months

1
0
0 0

Re: [TF-M] Old Mbed-Crypto library?

by Antonio De Angelis

Hi Andrej, TF-M Crypto has moved to use the same API as the latest available *release* of Mbed Crypto which is Mbed Crypto 1.0.0 . Mbed Crypto is a reference implementation of the PSA Crypto API, which are under active development. TF-M Crypto will align to newest release of Mbed Crypto when they will become available; these new releases will incorporate the new features which are developed as part of the PSA Crypto API, and there will be cases where the new features will break legacy code (i.e. API changes). Regarding the change that you mention, i.e. psa_key_slot_t vs psa_key_handle_t . The concept of psa_key_handle_t that TF-M Crypto is using now is indeed a newer (updated) concept introduced with later versions of the PSA Crypto API to replace the outdated concept of psa_key_slot_t. For example, if you look at the current latest development version of the PSA Crypto API, you will see that psa_key_handle_t is used to handle keys. This is an example of a breaking change in the API that has been introduced by newer releases of the PSA Crypto API. You are right, this change will break regression / PSA API compliance tests, in fact as part of the latest set of patches you can see that the Regression tests are upgraded to use the new concept of psa_key_handle_t instead of psa_key_slot_t. From these updated tests, you can get an idea of how to use the psa_key_handle_t. After this update, TF-M Crypto can't support the PSA API compliance tests (ACK) which were run previously (i.e. the ew_beta0 branch). The psa-arch-test team is in the process of providing an update on the master branch which will enable TF-M Crypto to run compliance tests from there. This should happen in the next couple of weeks. Please let me know in case you need any more clarification. Best regards, Antonio ________________________________ 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: 27 May 2019 12:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Old Mbed-Crypto library? Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Old Mbed-Crypto library?

by Andrej Butok

Hello, tfm_build_instruction.rst tells to use mbed-Crypto instead of mbedTLS: git clone https://github.com/ARMmbed/mbed-crypto.git -b mbedcrypto-1.0<https://github.com/ARMmbed/mbed-crypto.git%20-b%20mbedcrypto-1.0>.0 But the issue is that it references to the obsolete (3 month old) Mbed-Crypto library. Also, it looks like this old MbedCrypto has downgraded TFM/PSA Crypto API (from key-slot to key-handle) => this is step back in PSA TFM API, which should break crypto regression and PSA tests. We do not want to downgrade our SDK MbedCrypto, better to freeze TFM. Any plans to use the last Crypto Lib and to revert the PSA API degradation? Thanks, Andrej Butok

6 years, 9 months

1
0
0 0

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

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >Please see the following link for a design proposal on anti-rollback protection in trusted boot: > >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Somewhat related, as I've been working through a prototype implementation of SUIT, the SUIT manifest also wants what they call a "sequence number", which is a monotonically increasing number associated with each version. They've kind of decided they don't want to have to do anything like semantic version parsing as part of the firmware upgrade. I think this sequence number serves the same purpose as this security counter (except that the sequence number is required to increase with each software relase). One of the goals of the MCUboot community is to make sure that however the SUIT manifest is implemented, it must be semantically the same as the existing TLV-format manifest. An easy solution is to just treat the existing version as a 32-bit number (ignoring the build-id, which I think is supposed to be the case, anyway). As far as the possibility of re-using the same security counter value, I don't think that is something that should be done. In general, it isn't possible to know where security bugs will be found in an image. If we always increase the security counter value, someone still running the immediately following image will be prevented from rolling back to the version with the security flaw, whereas if we reused the values, it might be necessary to try to force them to upgrade to a new version that has the counter increased. Also, I think it is important to clarify that the security counter is not required for anti-rollback, it only protects the anti-rollback implementation from a specific threat: something that is able to replace the primary firmware image outside of the control of the bootloader. The cost is that implementing a security counter generally requires specific hardware just for that purpose. An entirely software anti-rollback protects against other threats, including the common case of using the ordinary firmware upgrade process. David

6 years, 10 months

2
3
0 0

Re: [TF-M] TFM and FreeRTOS

by Andrej Butok

Hello, So, the RTX was replaced by FreeRTOS (regression and psa-tests passed). Required changes: 1) Use CMSIS-FreeRTOS adapter from: https://github.com/ARM-software/CMSIS-FreeRTOS 2) Do not call os_wrapper_join_thread()/osThreadJoin() and do not use osThreadJoinable flag. It is not supported by FreeRTOS 3) Add missing osThreadExit(). 4) Add osDelay(1) to tfm_sst_run_test(), as FreeRTOS free some allocated resources only in the idle task. 5) Disable TFM_NS_CLIENT_IDENTIFICATION to avoid SVC conflict. 5) Other minor changes. Proposals for general TFM code: 1) Delete os_wrapper_join_thread()/osThreadJoin() as it is optional. It works without it and not supported by all RTOSes. 2) Add missing osThreadExit() to test_task_runner(). 3) Do not call each SST test in separate task, or to allow switching to idle task after each SST test. 4) Find other TFM_NS_CLIENT_IDENTIFICATION mechanism, which will not use SVC. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday, May 3, 2019 9:36 AM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hello, So, even if the unique User ID is optional, it is mandatory for the case when different NS users must have different security asset policies for SST resources. Is it possible to find another mechanism for the user ID assignment which does not use SVC? To avoid unwanted limitation for FreeRTOS and any other NS application using SVC. Thanks, Andrej -----Original Message----- From: Miklos Balint <Miklos.Balint(a)arm.com> Sent: Tuesday, April 30, 2019 5:19 PM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [TF-M] [EXT] Re: TFM and FreeRTOS Caution: EXT Email Hi Andrej, Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1). That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services. This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections." Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4. Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one. Let me know if you need further assistance in this matter. 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 12:47 To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: TF-M(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS Hi David, OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API. In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION. It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID. What does it mean? How does it limits the functionality? Is it OK from PSA point of view? Thanks, Andrej -----Original Message----- From: David Hu (Arm Technology China) <David.Hu(a)arm.com> Sent: Thursday, April 25, 2019 11:26 AM To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org Subject: [EXT] Re: [TF-M] TFM and FreeRTOS Caution: EXT Email Hi Andrej, I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following. In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does. FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities. By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core. Hope it can hlep you. Best regards, Hu Ziji On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote: > 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 > > 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://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, 10 months

1
0
0 0

Fixing implicit casting of C enumeration in TF-M: design document

by Hugues De Valon

Hi All, Please find under the following link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1040 the review of a design document which aim is to fix the implicit casting happening with enumerations in TF-M. Feel free to add any comments you want on the review! Kind regards, Hugues 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, 10 months

1
0
0 0

TF-M Crypto service design document

by Antonio De Angelis

Hi all, I have uploaded the design document for the TF-M Crypto service at the following Gerrit code review in RST format: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1023 It can be possible to render the HTML format of the design document by checking out the patch above and build the docs (in particular, by building the install_userguide target) Comments are welcome, here in this thread or preferably in the Gerrit review for better tracking. Thanks, Antonio

6 years, 10 months

1
0
0 0

SST 512B write support?

by Andrej Butok

Hello, Current TFM SST service supports 1, 2, 4 and 8 Byte minimum write. Do you have any plan to add the 512 Byte minimal write support to the TFM SST? LPC55S69 Flash has the 512Bytes program size. Guess, all flash modules with ECC has the same requirement. Thanks, Andrej Butok

6 years, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M