- TF-M - lists.trustedfirmware.org

Support for optional build for secure partitions and test suites

by Kevin Peng (Arm Technology China)

Hi, I've made some patches to support optional build for secure partitions and test suites: https://review.trustedfirmware.org/q/topic:%22optional_build_sp_and_tests%2… With this patch set, you can optionally build secure partitions by setting the TFM_PARTITION_XXX in CommonConfig.cmake around line 152 - 162. And for test suites, by setting ENABLE_XXX_TESTS in test/TestConfig.cmake. I'm collecting for review comments. Thanks. Best Regards, Kevin

5 years, 6 months

1
0
0 0

TF-M technical Forum slides and recording

by Bill Fletcher

Hi all, I've posted links to the (updated) slide deck and a recording of the call on the meetings page of the Trusted Firmware website: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Regards Bill -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 6 months

1
0
0 0

Adding Cypress PSoC64 platform support

by Christopher Brand

Hi, I recently pushed patches to add support for a platform based on Cypress' PSoC64 SoC to gerrit. Given that this is the first non-Arm platform to be posted, it seems worth drawing attention to. Comments very much appreciated. I do anticipate a few small updates to the patchset, even in the absence of comments. In particular, there are some documentation improvements to come. There are four patches in total, ending with https://review.trustedfirmware.org/c/trusted-firmware-m/+/2728 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2725/1 adds files to the platform/ext/cmsis directory, and so will affect/be affected by https://review.trustedfirmware.org/c/trusted-firmware-m/+/2578 Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 6 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by 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(a)iar.com> Sent: 02 December 2019 22:50 To: Jamie Fox <Jamie.Fox(a)arm.com>; Minos Galanakis <Minos.Galanakis(a)arm.com> Cc: nd <nd(a)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(a)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(a)arm.com><mailto:Minos.Galanakis@arm.com>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)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(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org><mailto:tf-m@lists.trustedfirmware.org> *Sent:* 28 November 2019 14:49 *To:* tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)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(a)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(a)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(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>

5 years, 6 months

2
3
0 0

X.509 Certificate Chain Support in TF-M

by Kevin Townsend

Hi, As part of some of our work on TF-M, specifically around attestation, device provisioning and firmware management, we've been reviewing some of what various companies are currently doing or requiring during the provisioning process (whether provisioning at the manufacturing phase, or provisioning devices into cloud or similar services post manufacturing). The common thread in almost all of these scenarios is the use of X.509 certification chains when working with the public key(s) held on the end device. At Linaro, we've been thinking through some of the benefits and tradeoffs of migrating from the current approach of exposing unsigned public keys for things like initial attestation and signing firmware, and what would be required to allow the signing of the attestation/firmware keys on devices, and generating new keys such as provisioning a device onto an Amazon/Google/Microsoft cloud service which would require creating a new private key held in secure storage, and storing the signed certificate chain associated with that new private key for on-demand retrieval. - Some of the initial thinking and imagined benefits of migrating to X.509 certificate chains are described here: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md - Some general notes on X.509 certificates are available here: https://github.com/microbuilder/certificate_chains/blob/master/README.md - And here are two scripts showing how to create 2 and 3 level certificate chains, just as a proof of concept to better understand how this might work with something like TF-M: - https://github.com/microbuilder/certificate_chains/blob/master/2lev_cert_cr… - https://github.com/microbuilder/certificate_chains/blob/master/3lev_cert_cr… Specifically, they key missing aspects to enable the use of standard X.509 certificates are: - Update mcuboot to understand a certificate chain -- rather than the raw public key -- when verifying firmware images - Generating PKSC#10 (RFC2986) certificate signing requests on the secure side, using a securely held private key during the request generation process - Generate new private keys and store them in secure storage for non-attestation uses like cloud services, and retrieve the associated and signed cert chains for that key on demand A proposal of how this might work in the real world is shown here, with the TF-M secure code requrements in the 'opt' box of the sequence diagram: https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md#c… We don't have a full TF-M proof of concept ready yet, but wanted to put the idea on the table of migrating to X.509 certificate chains while we work on a proof of concept, and continue analysis of how provision at manufacturing and in the field (to cloud services, etc.) can be improved. Any feedback/concerns is welcome here or perhaps in the Github repo above until a specific change request can be prepared for TF-M. Best regards, Kevin Townsend

5 years, 6 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

In our use case, we added complete paths to the build area's corresponding directory to the embedded include paths and removed the default generated content from our git repo. Consequently only the newly generated content is found, wherever it happens to be placed. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: Friday, November 22, 2019 2:15 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] Re: out of tree build Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

TF-M Technical Forum call - 5th December

by Bill Fletcher

Hi all, As mentioned in the TF-M workshop in Lyon last month, we propose to kick off the TF-M Technical Forum meeting, starting on the 5th December. This is an open forum for anyone to participate and it is not restricted to TF members. It will operate under the guidance of the TF TSC. - Due to expected attendees from Asia, Europe and the Americas, the timeslot is challenging. We hope it's not too difficult for anyone - we can review after the first couple of meetings. - Initially we propose a bi-weekly call and then we'll change cadence depending on interest For more details of the call click on the Google Calendar image at https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 6 months

1
0
0 0

TF-M RC3 release

by Tamas Ban

Hi, A new tag TF-Mv1.0-RC3 was created last Friday. The main change since RC2 is that it provides support for integrated Cryptocell-312 cryptographic hardware accelerator on MuscaB1e platform. This enables TF-M to make use of Cryptocell-312 (CC-312) for crypto acceleration during Secure boot and runtime. TF-M is also can use the provisioned HUK (Hardware Unique Key), Attestation key and RoTPK (Root of Trust Public Key) in Cryptocell's OTP memory. Tamas

5 years, 6 months

1
0
0 0

Re: [TF-M] Regression test issues with IAR port

by 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(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 28 November 2019 14:49 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)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\configs\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/non_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/non_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/non_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(a)iar.com <mailto:thomas.tornblom@iar.com> Website: 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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Regression test issues with IAR port

by Thomas Törnblom

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\configs\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/non_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/non_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/non_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(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>

5 years, 6 months

1
0
0 0

Re: [TF-M] PSA Certification without PS?

by Shebu Varghese Kuriakose

Hi Andrej/Kevin, Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile* It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met. PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage, maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform. @Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this >>> 5.3 F.SECURE_STORAGE The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to the platform. Only the TOE can retrieve and modify assets from this secure storage. This security function mitigates T.STORAGE by preventing direct and unprotected access to assets. >>> Regards, Shebu * https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le… ** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im… -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Thursday, November 28, 2019 7:50 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA Certification without PS? Hi Kevin, So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right? Thank you for your clarification, Andrej Butok -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>> Sent: Thursday, November 28, 2019 5:14 AM To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] PSA Certification without PS? A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----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: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- 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://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 6 months

3
3
0 0

Re: [TF-M] PSA Certification without PS?

by Kevin Peng (Arm Technology China)

A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Wednesday, November 27, 2019 7:32 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA Certification without PS? Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, all, Right, let's see the binary size of a prototype. Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 22 November 2019 10:23 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] The svcall switch-case vs function table Hi Anton, Thanks for the reminder. About code size, two points: - We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func(); - The compiler uses 'TBB' instruction, which is a function table already. So I think it should be okay; we can verify the code size after the prototype is available. BR /Ken -----Original Message----- From: Anton Komlev <Anton.Komlev(a)arm.com> Sent: Thursday, November 21, 2019 8:09 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: The svcall switch-case vs function table Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

PSA Certification without PS?

by Andrej Butok

Hello, Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash. Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API? Do you see any issue? Thanks Andrej Butok

5 years, 6 months

1
0
0 0

Re: [TF-M] Coding guideline

by Anton Komlev

Hello, I do also support the move to loose the requirement of 80 columns. The real need is outdated and supported as a legacy style, making more trouble than help. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Laurence Lundblade via TF-M Sent: 26 November 2019 21:12 To: Tamas Ban <Tamas.Ban(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline For line length I’m following these rules for t_cose <https://github.com/laurencelundblade/t_cose> - All comments blocks are 80 columns or less - 2% of code lines can be over 80 columns (1% is too few) - No lines over 120 columns I am much happier and think the code is much better by allowing 2% of code lines over 80 columns. I don’t have to make variable names short and obscure, break up if statements in unnatural places, break up for(;;) statements unnaturally and such. LL > On Nov 18, 2019, at 8:31 AM, Tamas Ban <Tamas.Ban(a)arm.com> wrote: > > Hi, > > I would like to open a conversation about TF-M coding guideline <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: > Change the rule of the 80 character column width: > Max 80 characters length. > Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: > Degrades code understandability: short, obscured variable names; > awkward line breaks Maximum 1% of the lines can exceed 80 charter length. > Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: > o Order function parameters so that input params are before output params. > o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…> > > I’m interested in your opinions! Other rules also can be revisited! > > Tamas -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Using git submodules for dependencies?

by Gyorgy Szing

Hi, Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer. Some of the issues which came to my mind: 1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module. 2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms. 3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module. 4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need. 5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be. Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies. /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 26 November 2019 19:23 To: Kumar Gala <kumar.gala(a)linaro.org> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Using git submodules for dependencies? Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things > you mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli > ght=external > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible > > (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked > out only once it was considered acceptable nuisance, until you do a > pull and version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to > > handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > >> Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting > >> TF-M > working with QEMU. Part of that work is simplifying the setup and > build process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, > >> and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it > >> seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> 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%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2 > b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG > bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0 > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Coding guideline

by Tamas Ban

Hi, I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: * Change the rule of the 80 character column width: * Max 80 characters length. * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: * Degrades code understandability: short, obscured variable names; awkward line breaks * Maximum 1% of the lines can exceed 80 charter length. * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: o Order function parameters so that input params are before output params. o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… I'm interested in your opinions! Other rules also can be revisited! Tamas

5 years, 6 months

2
1
0 0

Re: [TF-M] Using git submodules for dependencies?

by Kevin Townsend

Hi, I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases. I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than 1+4 independent repos both for TF-M and any projects on the RTOS side depending on it? Kevin On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > How would a git repo with some submodules preclude any of the things you > mentioned? I guess my initial thought is that there would be an “uber” > repo in which TFM, CMSIS and mbedcrypto would all be sub-modules. > > There’s also the option of using cmake ExternalProject ( > https://cmake.org/cmake/help/latest/module/ExternalProject.html?highlight=e… > ) > > Or west > > https://pypi.org/project/west/ > > - k > > > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > > > > Hi, > > > > Initial idea was to keep the external dependencies clearly visible (from > code auditability point of view). With submodule we can't checkout the > dependencies out of tree. Since the dependencies need to be checked out > only once it was considered acceptable nuisance, until you do a pull and > version of the dependencies have changed. > > 'repo' was considered as well, but repo tool doesn't work on > windows(last I checked). > > > > Thanks, > > Ashu > > > > -----Original Message----- > > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar > Gala via TF-M > > Sent: 10 July 2019 09:50 > > To: Andrej Butok <andrey.butok(a)nxp.com> > > Cc: tf-m(a)lists.trustedfirmware.org > > Subject: Re: [TF-M] Using git submodules for dependencies? > > > > There can always be a fork of the sources kept in TF-M repos to handle > the case of needing local modifications for some reason. > > > > - k > > > >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M < > tf-m(a)lists.trustedfirmware.org> wrote: > >> > >> Hi Kevin, > >> > >> Only if 100% of the external project source code is used without > change. > >> Even if it is valid now, nobody will give you this guarantee in future. > >> > >> Regards, > >> Andrej > >> > >> -----Original Message----- > >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > >> Sent: Wednesday, July 10, 2019 10:41 AM > >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > >> Subject: [TF-M] Using git submodules for dependencies? > >> > >> Hi, > >> > >> I'm currently working on integrating TF-M into Zephyr and getting TF-M > working with QEMU. Part of that work is simplifying the setup and build > process to generate a TF-M secure library. > >> > >> Was the idea of git submodules for dependencies considered and rejected? > >> Using sub-modules would reduce the number of setup steps required, and > pair external dependency versions with specific TF-M commits/releases. > >> > >> There may be a valid reason this approach was rejected, but it seems > like a sensible option on the surface? > >> > >> Best regards, > >> Kevin Townsend > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… > >> -- > >> TF-M mailing list > >> TF-M(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > > TF-M mailing list > > TF-M(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 6 months

1
0
0 0

Design proposal for enabling byte-aligned flash devices.

by Minos Galanakis

Hi all, I have recently submitted the following design proposal, currently under review, which is aimed at enabling byte-aligned flash devices on TF-M https://review.trustedfirmware.org/c/trusted-firmware-m/+/2392 Any feedback, suggestions would be greatly appreciated. Regards, Minos Galanakis

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Qixiang, It is a very reasonable suggestion. I will write it down as a further improvement. Thanks a lot. Best regards, Hu Ziji -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] Including board-specific libraries in TF-M

by Tamas Ban

Hi Kevin, Currently there is no established pattern how to link a library to secure code on platform level. Currently only services and crypto libraries are built as libraries but not platform code. I think the suggested solution (put a `target_link_libraries` entry in that platform/ext/*.cmake file) is feasible, because the platform level cmake files are included by the secure_fw/CMakeList.txt (through CommonConfig.cmake) and in this way the library will be linked to secure code. We have similar solution in case of CC312 library integration: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2526/6/platform… Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 25 November 2019 16:47 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Including board-specific libraries in TF-M Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Qixiang Xu (Arm Technology China)

Correct the mail list address to send it again. -----Original Message----- From: Qixiang Xu (Arm Technology China) Sent: Tuesday, November 26, 2019 2:18 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org. Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, When we add a platform into the TF-M, we need modify the top makefile to add it into build the system build, maybe we can consider to fix this issue at the same time. My proposal has changed a little from your proposal: ├── ext │ ├── arm │ │ ├── common │ │ │ └── arm_common.c │ │ ├── mps2 │ │ │ ├── an519 │ │ │ │ ├── an519.c │ │ │ │ └── plat.cmake │ │ │ ├── an521 │ │ │ │ ├── an521.c │ │ │ │ └── plat.cmake │ │ │ ├── an539 │ │ │ │ ├── an539.c │ │ │ │ └── plat.cmake │ │ │ ├── mps2.cmake │ │ │ └── mps2_common.c │ │ ├── mps3 │ │ │ ├── an524 │ │ │ │ ├── an524.c │ │ │ │ └── plat.cmake │ │ │ ├── mps3.cmake │ │ │ └── mps3_common.c │ │ └── musca │ │ ├── a │ │ │ ├── a.c │ │ │ └── plat.cmake │ │ ├── b1 │ │ │ ├── b1.c │ │ │ └── plat.cmake │ │ ├── musca.cmake │ │ ├── musca_common.c │ │ └── s1 │ │ ├── plat.cmake │ │ └── s1.c │ └── vendor1 │ ├── board1 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ ├── board2 │ │ ├── board1.cmake │ │ ├── board1_common.c │ │ ├── var1 │ │ │ ├── plat.cmake │ │ │ └── var1.c │ │ └── var2 │ │ ├── plat.cmake │ │ └── var2.c │ └── common │ └── vendor1_common.c In the different vendor, we have different boards and the board have different variants, so the plat.cmake can include the boardx.cmake and the boardx.cmake can include the vendorx.cmake. To build the TF-M, we change the command line from PLAT=xxxx to PLAT=vendorX/boardY/varZ. The top makefile finds the plat.cmake from the platform directory with PLAT variable which passed by command line. So we don't need touch the top makefile when we add a new platform. Thanks. Best Regards, Qixiang Xu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 26, 2019 11:05 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Edison, IMO, `target` folder is still required to separate the platforms from common files and drivers. Best regards, Hu Ziji -----Original Message----- From: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com> Sent: Monday, November 25, 2019 11:48 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Z` The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 6 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Edison Ai (Arm Technology China)

Hi David, Support the idea to support more different platforms and common drivers. One suggestion for your proposal, is it necessary to add the "target" folders? It looks like we can short the folder depth. What about this? Platform |-- ext | |--Partner ABC | | |-- *common drivers and files* | | |-- target_abc_1 | | | |-- target_abc_1.cmake | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- *common drivers and files* | | |-- target_xyz_1 | | | |-- target_xyz_1.cmake | | |-- target_xyz_2 | |-- ... |--include Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Monday, November 25, 2019 10:33 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
1
0 0

Including board-specific libraries in TF-M

by Kevin Townsend

Hi, While working on upstreaming support for a new MCU in TF-M, I've bumped into a requirement to link against an external library that's required for the device init sequence. I may (or may not) be able to remove this dependency, but is there currently a cross-platform mechanism to link .a files (etc.) during the build process at the platform/ext/*.cmake level? It's possible to put something together for this one target ('target_link_libraries'???), but I was wondering if I'm missing an instance where this is handled at a higher level, similar to how the RTX library is handled in the same makefiles: if (DEFINED CMSIS_5_DIR) # Not all projects define CMSIS_5_DIR, only the ones that use it. set(RTX_LIB_PATH "${CMSIS_5_DIR}/CMSIS/RTOS2/RTX/Library/GCC/libRTX_V8MMN.a") endif() Best regards, Kevin

5 years, 6 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Thanks for your inputs. The original intention of the script was to not to modify the origin of the information i.e rst file as Minos quoted and also to avoid duplication of information. Considering all the new information, I think we should try to separate build and post-build dependencies (ex: srec_cat). This separation will allow us to handle all the build dependencies using "cmake" and then we can explore the possible option on how to handle post-build dependencies. @Minos, I believe all sw dependencies defined in https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… are already validated in cmake. Adding other library dependencies into it will make it complete. This way we don’t need mention library dependency in document anymore and still achieve single source of information. @George, I think first 3 question can be answered if we decide to go ahead with handling build dependencies with cmake. Thanks, Dev On 21/10/2019, 15:56, "TF-M on behalf of Gyorgy Szing via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 6 months

2
5
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Adrian Shaw

Page 43 of the PSA Firmware Framework states the following: 1. Even when using these techniques, the latency involved in scheduling a Secure Partition to handle interrupts might not be acceptable for certain types of peripheral. The SPM can implement its own independent device driver model, which provides improved response latency, however, this comes at the cost of portability and security. The SPM’s independent device driver model is not within the scope of this specification. So you are allowed (if you want to implement it in an SP). Best, Adrian On 19 Nov 2019, at 08:07, Edison Ai (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi Alan, Thanks for your information. So I think there are 2 discussion here: 1. You had met unexpected behavior when a secure interrupt is configured with a lower priority than pendsv. As I understand, if you just move the pendsv in a higher priority, it should be ok. Just as I say in former mail that the pendsv handler will be processed every time, but it still can works. In this case, the 'd' point you list should not extend to SP. 2. You say that "the SP while it is processing the ISR". Do you mean you want to add a SP ISR? Right? please correct me if it is not. If so the current discussion should be if it is allowed to process ISR in SP: - If allow, "A NSPE interrupt is not allowed to preempt SPE ISR" could be understood as a NSPE interrupt is not allowed to preempt SP ISR. So I think this why you assume the SPE needs to be restored to the IDLE state. - If no. you assume will not reasonable. I think the answer should be NO. PSA FF gives us several APIs to process the interrupt: psa_wait, psa_get, psa_eoi based on the message in the IPC model. In this mechanism, ISR needs to send a signal to SP and let SP process data after scheduling. It is cleaner and security. Thanks, Edison -----Original Message----- From: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Sent: Friday, November 15, 2019 4:48 AM To: Edison Ai (Arm Technology China) <Edison.Ai(a)arm.com<mailto:Edison.Ai@arm.com>> Cc: 'tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: RE: [EXTERNAL] RE: secure interrupt handlng in IPC mode I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m 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.

5 years, 7 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi Andrei, Thanks a lot for the positive feedback. Adding another common layer for all the partners sounds similar to Andrej's proposal. In my very own opinion, currently CMSIS can cover the general arch features. The general multi-core mailbox code is kept in TF-M Core. But I won't be surprised if additional common features should be extracted and kept under platform folder. Apparently, we need more partners/platforms on TF-M to specify the requirements. I'd suggest that we can discuss the additional common part as another topic in a separated email thread. Best regards, Hu Ziji -----Original Message----- From: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Sent: Saturday, November 23, 2019 3:49 AM To: David Hu (Arm Technology China) <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: [RFC] Re-organize the TF-M platform folder structure Hi David, I support this idea as it is a quick and easy solution for the growing list of supported platforms. Perhaps, I would also add another common layer in platform/ext/target to keep platform code that can be reused by other partners in their platforms - for the multicore mailbox code, for example. Thanks, Andrei -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, November 19, 2019 7:20 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

1
0
0 0

Add hooks for build artifacts custom post-processing

by Andrei Narkevitch

Hi All, I'd like to propose a small change that allows to implement custom build artifacts post processing. In our case, we need to convert tfm_s and tfm_ns binaries into a different file format and implement our custom signing. I expect that other partners eventually may have the same need for build customization. With this, user has an option to implement compiler_custom_post_build command in platform/ext/<platform>.cmake file, and put there all additional custom operations. If command is not implemented, it will be simply ignored. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2588 thanks Andrei This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

1
0
0 0

Fix for broken AN539 build

by Jamie Fox

Hi all, The build is currently broken for AN539 due to a missing include, so I pushed a quick patch to fix it: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2607 Would appreciate it if anyone with a couple of minutes could review it so that we can merge it quickly. Many thanks, Jamie

5 years, 7 months

1
0
0 0

Re: [TF-M] The svcall switch-case vs function table

by Anton Komlev

Hi Ken, All, Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase. This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment. The best, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: 14 November 2019 09:33 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] The svcall switch-case vs function table Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 7 months

2
1
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by Kevin Peng (Arm Technology China)

Hi all, I'm having issues on supporting the out of tree build. So I'd like to propose some additional changes. What does the out of tree build currently support is that: The user uses the tfm_parse_manifest_list.py with the custom manifests to generate the customized files to a directory out of TF-M. And the TF-M build system uses the customized files rather than the pre-generated ones in the TF-M for building. The problem is that some of the source files include the generated headers using the relative path to where the source itself is. And the directory of the source file is always searched first. This makes it impossible to use the generated files outside TF-M even the custom output directory is added to searching list. So I suggest to put the generated files to a dedicated directory in TF-M. Then for the default build, add the directory and its subdirectories to the search list for headers. For out of tree build, use the specified directory and its subdirectories instead. Then there would only one header file with the same name in all the directories for searching headers. Any concerns, thoughts or suggestions? Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Friday, November 22, 2019 3:45 PM To: DeMars, Alan <ademars(a)ti.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build Hi Alan, I've created a patch for the tfm_parse_manifest_list.py as the first step for the out of tree build support: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2606 The changes for build system is ongoing. The functionality changes for the tfm_parse_manifest_list.py is the same as your version. Please have a review and help verify it if possible. Comments from anyone else are also welcome. Best Regards, Kevin -----Original Message----- From: Kevin Peng (Arm Technology China) Sent: Thursday, November 14, 2019 3:31 PM To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [EXTERNAL] Re: [TF-M] out of tree build OK. It's much clearer for me now. Thanks. Best Regards, Kevin -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:34 AM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [EXTERNAL] Re: [TF-M] out of tree build 1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Coding guideline

by Abhishek Pandit

Hi Reinhard, We had a discussion in the TSC last week about coding standard. The general consensus was that there multiple possible standards that we can aim for but we need to decide our goal in order to decide the coding standard for the project. I believe Mark G is planning to look at the work ongoing in Zephyr project and provide some details to help us take the discussion forward for TF.org. The input below is helpful, we should take this into the unified effort for coding standard and tooling to enforce it. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: 22 November 2019 07:59 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Coding guideline

by Reinhard Keil

Hi all, I suggest to use industry standard coding rules. Here are the CMSIS coding rules: https://arm-software.github.io/CMSIS_5/General/html/index.html#CodingRules Simple, as we use MISRA. MISRA is an accepted set of coding standards, why invent something new? For wide acceptance of TF-M in automotive/industrial projects, you should publish also deviations like here: https://arm-software.github.io/CMSIS_5/RTOS2/html/misraCompliance5.html Reinhard 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: out of tree build

by DeMars, Alan

1) I verified the tfm_parse_manifest.py script changes using the master branch’s version of the tfm_manifest_list.yaml and tfm_generated_file_list.yaml files. 2) Yes, I’m building using the unmodified master branch’s cmake build system. 3) Just as all other build artifacts are placed in the user’s build directory and NOT in the source tree, the generated files should also. Otherwise, the user is required to update the source tree’s tfm_manifest_list.yaml and tfm_generated_file_list.yaml files to build a custom SPE, with the generated files also ending up in the source tree. The files necessary to create a custom SPE should not be kept in the source tree. Nor should the generated content be inserted in the source tree. This creates headaches for maintaining the original source tree. Alan > On Nov 13, 2019, at 1:57 AM, Kevin Peng (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > I checked your modified tfm_parse_manifest_list.py. > It basically uses the input tfm_manifest_list.yaml and tfm_generated_file_list.yaml to generate the TF-M auto generated files to the third input. > > I'm sorry I was not in the workshop. So I have some questions. > 1. Do you have your own tfm_manifest_list.yaml and tfm_generated_file_list.yaml that is not upstreamed in TF-M? > 2. Are you using the TF-M provided CMake build system? > 3. Do you only need the files generated by tfm_parse_manifest_list.py to be out of the TF-M source directory? > > Could you provide some details about your requirements. Thanks. > > Best Regards, > Kevin > > -----Original Message----- > From: Kevin Peng (Arm Technology China) > Sent: Wednesday, November 13, 2019 10:27 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: RE: out of tree build > > Hi Alan, > > I'm following on this and will get you updated on any progress. > > Best Regards, > Kevin > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, November 7, 2019 12:42 PM > To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> > Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: Re: [TF-M] out of tree build > > Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. > --- > > With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: > > python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> > > And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: > > cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. > > Alan > > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M > Sent: Monday, November 4, 2019 4:36 PM > To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] Re: [TF-M] out of tree build > > Abishek, > > Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. > A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. > > I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. > > Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. > > Alan > > -----Original Message----- > From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] > Sent: Monday, November 4, 2019 3:08 PM > To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org > Subject: [EXTERNAL] RE: out of tree build > > Hi Alan, > Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? > Thanks, > Abhishek > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: 01 November 2019 16:29 > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] out of tree build > > Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
2
0 0

Re: [TF-M] Call for review on header include update

by Abhishek Pandit

Hi Kevin, Yes my email was meant to be on the mailing list. Added back on. Thanks Abhishek -----Original Message----- From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Sent: 21 November 2019 09:13 To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Subject: RE: Call for review on header include update Hi Abhishek, [I guess you are trying to reply to mailing list as well?] I think it's mostly about coding style. Most of the headers are included without any relative path in TF-M. So it's wired that lots of headers are included by a relative path, and relative to the project root make it even more unreasonable. The reason I didn't explain it in detail is that I didn't find any documents about this code style. Of course I had discussions with some team members and they are feeling the same. So I'd like to hear more feedbacks first. Best Regards, Kevin -----Original Message----- From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Thursday, November 21, 2019 4:54 PM To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Call for review on header include update Hi Kevin, Is there something that explains why this is required? Thanks Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng (Arm Technology China) via TF-M Sent: 21 November 2019 08:38 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Call for review on header include update Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Gerrit dashboard for TF-M

by Soby Mathew

Hi, I have created a dashboard for the TF-M project on tf.org to better visualize outstanding patches and the state of patch review : https://review.trustedfirmware.org/#/projects/trusted-firmware-m,dashboards… (old Gerrit UI) https://review.trustedfirmware.org/p/trusted-firmware-m/+/dashboard/site:ma… (new UI) Best Regards Soby Mathew

5 years, 7 months

1
0
0 0

Call for review on header include update

by Kevin Peng (Arm Technology China)

Hi, I've proposed some patches to update the header includes in TF-M: https://review.trustedfirmware.org/q/topic:%22include_path_update%22+(statu… The idea is to remove the relative paths to TF-M root and add the necessary paths to include search list. Any kinds of comments are welcome. Best Regards, Kevin

5 years, 7 months

1
0
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Andrej Butok

Hi David, Let's go further. The main goal of the proposal should be to have the all TFM portable code in one place as much as possible - so the top folder is named as "port". New proposed structure: port |-- platform | | | |-- Partner ABC | | |-- common | | |-- target_abc_1 | | |-- target_abc_2 | | | |-- Partner XYZ | | |-- common | | |-- target_xyz_1 | | |-- target_xyz_2 | |-- ... | -- arch | -- include Thanks, Andrej -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 4:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 7 months

2
1
0 0

Re: [TF-M] [RFC] Re-organize the TF-M platform folder structure

by Ken Liu (Arm Technology China)

Hi David, The concept itself looks ok for me. So that the scope of vendor would be much clearer. And I think some structure change out of platform folder needs to happen to cooperate with this change, hope to see the detailed analysis result of the changes to be made. Thanks. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Wednesday, November 20, 2019 11:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Re-organize the TF-M platform folder structure Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

[RFC] Re-organize the TF-M platform folder structure

by David Hu (Arm Technology China)

Hi all, I'd like to propose to adjust the platform folder structure. Would you please check the details below and share your opinions? Any suggestion or feedback will be very helpful. In current platform folder structure, all the targets are listed together at the same level under `target` folder. Platform |-- ext |-- . |-- target_xxx.cmake |-- . |-- target_zzz.cmake |-- target |-- mps2 |-- musca_a |-- . A drawback is that, there are many duplicated files in those targets folders. It may become difficult to maintain the target support when targets, platforms, drivers and features continue growing. - A platform may have a series of variants. If each variant target folder has to contain a copy of platform drivers or library, it is difficult to align and maintain the duplicated drivers. - All targets belonging to the same platform contain the duplicated common operation files or configurations, such as HUK, NV counter and platform configurations. A small change has to be applied to multiple identical files. To solve the duplicated files management issue, I'd propose to insert partner folders under `target` and move the targets under the partner folder. The proposed structure looks like the following: Platform |-- ext |-- target | |-- Partner ABC | |-- *common drivers and files* | |-- target_abc_1 | | |-- target_abc_1.cmake | |-- target_abc_2 | |-- Partner XYZ | |-- *common drivers and files* | |-- target_xyz_1 | | |-- target_xyz_1.cmake | |-- target_xyz_2 |-- ... The ideas behind the proposal: - It is more close to the platform support structure in popular RTOSs. It can be more convenient for partners to port platform support to TF-M from existing projects. - Common drivers and operations implementations can be gathered into partner/platform specific folder. Thus each partner/platform folder doesn't have to hold a duplicated copy. - It is easier for partners to fully organize and maintain their platform folders with full permission. More layers can be added under a specific partner folder, such as diverse platforms. - Put the target specific cmake config file back into the target folder. It can make the `platform` folder much more clear. Best regards, Hu Ziji

5 years, 7 months

1
0
0 0

Re: [TF-M] Coding guideline

by Ken Liu (Arm Technology China)

Hi Tamas, The guidelines look good. I would suggest distinguishing these rules between `original tfm created sources` and `3rd party` sources because tfm is now involving some 3rd party projects and we should keep their original taste as much as we could. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: Tuesday, November 19, 2019 11:22 PM To: Kevin Townsend <kevin.townsend(a)linaro.org> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Coding guideline I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project > added to make enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.c > fg > > The advantage here is that most text editors can be configured to > automatically apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: >> >> * Change the rule of the 80 character column width: >> * Max 80 characters length. >> * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: >> * Degrades code understandability: short, obscured variable names; awkward line breaks >> * Maximum 1% of the lines can exceed 80 charter length. >> * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: >> >> o Order function parameters so that input params are before output params. >> >> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… >> >> I'm interested in your opinions! Other rules also can be revisited! >> >> Tamas >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

CC312 (crypto HW accelerator) integration on Musca-B1

by Tamas Ban

Hi, Musca-B1 board is the target of PSA Level 2 certification. As part of this process we integrated the CC312 crypto HW accelerator with TF-M. The following major changes was done: * Replacement of mbedTLS library to mbed-crypto in MCUBoot. * Integration of CryptoCell-runtime-library to TF-M build system. * Default behaviour of Musca-B1 is unchanged, it use SW only crypto and relying only on mbed-crypto. HW accelerated crypto can be turned on with CMake command line switch: -DCRYPTO_HW_ACCELERATOR=ON * When HW crypto acceleration is enabled then CryptoCell-runtime-library and CC312 HW perform the crypto operations instead of mbed-crypto (mbedTLS). The library provides an mbedTLS compliant API, therefore it requires minimal modification in the code base. * Creating a crypto key provisioning tool to program the TF-M related crypto keys to OTP memory (HUK, ROTPK, attest priv. key). Here we took a sort-cut and currently linked this tool to MCUBoot on demand. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING * Porting of platform layer in Musca-B1 folder to rely on CC312 and OTP memory. CMake command line switch: -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ENABLED * Extends initial attestation API to provide a public API to retrieve the public part of the attestation key. The top of the patch-set: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2539/ We would like to review and merge the changes by 27th of November! Reviewers are welcome! Tamas Ban

5 years, 7 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kumar Gala

I’ve been curious if something like https://lgtm.com/ could be used to have checks for code guidelines. - k > On Nov 19, 2019, at 8:22 AM, Kevin Townsend via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Tamas, > > Just to add to the conversation, something that the Zephyr project added to make > enforcing the coding guidelines easier was a config file for uncrustify. > > https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify > > The Zephyr config file itself can be seen here: > https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg > > The advantage here is that most text editors can be configured to automatically > apply these rules and avoid common white space or other issues. > > I've generally found this very useful generating PRs and just ensuring > I didn't make > any obvious errors when I commit files or changes. > > Best regards, > Kevin > > > On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M > <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi, >> >> I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: >> >> * Change the rule of the 80 character column width: >> * Max 80 characters length. >> * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: >> * Degrades code understandability: short, obscured variable names; awkward line breaks >> * Maximum 1% of the lines can exceed 80 charter length. >> * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: >> >> o Order function parameters so that input params are before output params. >> >> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… >> >> I'm interested in your opinions! Other rules also can be revisited! >> >> Tamas >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Coding guideline

by Kevin Townsend

Hi Tamas, Just to add to the conversation, something that the Zephyr project added to make enforcing the coding guidelines easier was a config file for uncrustify. https://docs.zephyrproject.org/latest/contribute/index.html#uncrustify The Zephyr config file itself can be seen here: https://github.com/zephyrproject-rtos/zephyr/blob/master/.uncrustify.cfg The advantage here is that most text editors can be configured to automatically apply these rules and avoid common white space or other issues. I've generally found this very useful generating PRs and just ensuring I didn't make any obvious errors when I commit files or changes. Best regards, Kevin On Mon, 18 Nov 2019 at 17:31, Tamas Ban via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals: > > * Change the rule of the 80 character column width: > * Max 80 characters length. > * Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character: > * Degrades code understandability: short, obscured variable names; awkward line breaks > * Maximum 1% of the lines can exceed 80 charter length. > * Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API: > > o Order function parameters so that input params are before output params. > > o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… > > I'm interested in your opinions! Other rules also can be revisited! > > Tamas > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

T398/T413, uploaded

by Thomas Törnblom

I have just uploaded the first of a set of changes to allow building TF-M with the IAR toolchain. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2560 Please review. Thanks, 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>

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by DeMars, Alan

I don't know that the SPE needs to be restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. I just assumed that these 2 rules required it: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR (I assumed that this rule applies to the SP while it is processing the ISR as well). Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Edison Ai (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 12:58 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Re: [TF-M] Commonly accepted default documentation layout

by Christopher Brand

I think you're right that we need some rules like this, and the list below looks reasonable to me. The list should probably be a document in its own right... Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos > Galanakis via TF-M > Sent: Thursday, November 14, 2019 3:14 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Commonly accepted default documentation layout > > Hi > > With our documentation growing, and more people contributing to it, it is > quite essential to start a discussion on some basic commonly accepted rules > about the format of choice. > > Restructured text allows you to achieve similar looking results using multiple > approaches, but this makes it harder for tools like Sphinx to render properly, > since the rendering template can be applied on per project basis, not on a > per file basis. > I took the liberty of investigating the existing documentation, and mostly > looking for top level headers which can be done by using either > > > > #################### > > This is a top-level header > > #################### > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > # Reference docs: > # user_guides/tfm_secure_boot.rst > # user_guides/tfm_user_guide.rst > > > > > > or > > > ==================== > This is a top level header > ==================== > > # Reference docs: > # design_documents/tfm_its_service.rst > # design_documents/secure_boot_hw_key_integration.rst > > > > > Since we are looking for the path of least resistance, I would like to propose > that we follow the format the majority of document uses.This is the format > used in > `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted- > firmware-m.git/plain/docs/user_guides/tfm_user_guide.rst>` . > > When writing a document and coming across a requirement that has not > been defined yet, we should be aiming for compliance with official Python > guidelines<https://devguide.python.org/documenting/#style-guide> which > is the most commonly used notation. > > The following rules should be considered: > > > 1. H1 document title headers should be expressed by # with over-line (rows > on top and bottom) of the text > 2. Only ONE H1 header should allowed per document, ideally placed on top > of the page. > 3. H2 headers should be expressed by * with over-line > 4. H2 header's text should be UNIQUE in per document basis > 5. H3 headers should be expressed by a row of '=' > 6. H4 headers should be expressed by a row of '-' > 7. H3 and H4 headers have no limitation about naming. They can have > similar names on the same document, if they have different parents. > 8. H5 headers should be expressed by a row of '^' > 9. H5 headers will be rendered in document body but not in menus on the > navigation bar. > 10. Do not go deeper than 5 level of heading > 11. When writing guide, which are expected to be able to be readable by > command line tools, it would be best practice to add long complicated tables, > and UML diagrams in the bottom of the page and using internal > references(auto-label). See the current version of the > `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/tru > sted-firmware-m.git/plain/docs/user_guides/tfm_sw_requirement.rst>` > and the proposed patch<https://review.trustedfirmware.org/c/trusted- > firmware-m/+/2456> > > Please let me know if you have any questions/objection or proposals or new > rules you would like to be considered. > > > Thanks, > Minos > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

1
0
0 0

New platform in TF-M: Musca-S1

by Mate Toth-Pal

Hi All, TF-M support for a new platform Musca-S1 is on review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2452/ We are planning to merge the patch this week. Comments are welcome on the review. Regards, Mate

5 years, 7 months

1
0
0 0

Commonly accepted default documentation layout

by Minos Galanakis

Hi With our documentation growing, and more people contributing to it, it is quite essential to start a discussion on some basic commonly accepted rules about the format of choice. Restructured text allows you to achieve similar looking results using multiple approaches, but this makes it harder for tools like Sphinx to render properly, since the rendering template can be applied on per project basis, not on a per file basis. I took the liberty of investigating the existing documentation, and mostly looking for top level headers which can be done by using either #################### This is a top-level header #################### # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst # Reference docs: # user_guides/tfm_secure_boot.rst # user_guides/tfm_user_guide.rst or ==================== This is a top level header ==================== # Reference docs: # design_documents/tfm_its_service.rst # design_documents/secure_boot_hw_key_integration.rst Since we are looking for the path of least resistance, I would like to propose that we follow the format the majority of document uses.This is the format used in `user_guides/tfm_user_guide.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` . When writing a document and coming across a requirement that has not been defined yet, we should be aiming for compliance with official Python guidelines<https://devguide.python.org/documenting/#style-guide> which is the most commonly used notation. The following rules should be considered: 1. H1 document title headers should be expressed by # with over-line (rows on top and bottom) of the text 2. Only ONE H1 header should allowed per document, ideally placed on top of the page. 3. H2 headers should be expressed by * with over-line 4. H2 header's text should be UNIQUE in per document basis 5. H3 headers should be expressed by a row of '=' 6. H4 headers should be expressed by a row of '-' 7. H3 and H4 headers have no limitation about naming. They can have similar names on the same document, if they have different parents. 8. H5 headers should be expressed by a row of '^' 9. H5 headers will be rendered in document body but not in menus on the navigation bar. 10. Do not go deeper than 5 level of heading 11. When writing guide, which are expected to be able to be readable by command line tools, it would be best practice to add long complicated tables, and UML diagrams in the bottom of the page and using internal references(auto-label). See the current version of the `/user_guides/tfm_sw_requirement.rst<https://git.trustedfirmware.org/trusted-firmware-m.git/plain/docs/user_guid…>` and the proposed patch<https://review.trustedfirmware.org/c/trusted-firmware-m/+/2456> Please let me know if you have any questions/objection or proposals or new rules you would like to be considered. Thanks, Minos

5 years, 7 months

1
0
0 0

The svcall switch-case vs function table

by Ken Liu (Arm Technology China)

Hi, I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations. Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros? This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros. Welcome to comment or propose patches for this. Thanks. /Ken

5 years, 7 months

1
0
0 0

Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode

by Edison Ai (Arm Technology China)

Hi Alan, I have one question, why the SPE needs restored to its IDLE state prior to a thread pre-empting NS interrupt occurring? About a secure interrupt is configured with a lower priority than pendsv, I do not think it is a good idea. The pendsv is used to trigger the scheduler to switch thread. The normal interrupt process should like this: Interrupt happen -> jump into related ISR -> do necessary process such as mask interrupt status, send even or signal to related SP. -> set pendsv to trigger scheduler -> jump out ISR -> scheduler to decide which thread to run. In these sequences, if there are many interrupts happen at the same time, and high priority interrupt will interrupt low priority interrupt. Each ISR will trigger pendsv. But only one pendsv hander function needs to be processed. If we set the pendsv with high priority. Each interrupt will trigger pendsv and the pendsv handler will be processed every time. It will be more complex and spend more CPU time. Sorry that I do not know what is your detail scenario, and it will be more clear and helpful if you can provide more information. Thanks, Edison -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M Sent: Thursday, November 14, 2019 3:12 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan, I have created the cooperative scheduling doc link here for comment: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2466 BR /Ken -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: Thursday, November 14, 2019 10:44 AM To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: Re: [EXTERNAL] RE: secure interrupt handlng in IPC mode Mate, Apart from the surprising behavior actually working to my benefit, my concern is the implications of violating the Cooperative Scheduling Rules I quoted below. The normal behavior (ie the SP running in thread mode with no exception priority when servicing a secure interrupt) seems to violate those rules. Is this a problem for the scheduler? Alan > On Nov 13, 2019, at 5:08 AM, Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> wrote: > > Hi Alan, > > That's a quite difficult question I think. > > At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. > > However implementing this seems to be a nontrivial task. > > The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. > > The phenomenon we observed with your setup was the following: > 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. > 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. > 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. > 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' > > Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. > > To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. > > The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. > > Regards, > Mate > > From: DeMars, Alan <ademars(a)ti.com> > Sent: 12 November 2019 17:47 > To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> > Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Subject: RE: secure interrupt handlng in IPC mode > > You can CC the tf-m mailing list. > > From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] > Sent: Tuesday, November 12, 2019 8:02 AM > To: DeMars, Alan > Cc: Ken Liu (Arm Technology China) > Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode > > Hi Alan > > Would it be OK to you if I cc the TF-M mailing list in my answer? > > Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. > > Thanks, > Mate > > > From: DeMars, Alan <mailto:ademars@ti.com> > Sent: 11 November 2019 21:05 > To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> > Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> > Subject: secure interrupt handlng in IPC mode > > Hi Mate! > > I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. > > I think the below statements in the Cooperative Scheduling Rules discussion: > > a. All of the SPE interrupts must have higher priority than NSPE > interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must > extend to the priority level of the SP as it services the interrupt while in thread mode. > > Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. > > So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. > > Is this correct thinking? > > Alan > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] secure interrupt handlng in IPC mode

by Mate Toth-Pal

Hi Alan, That's a quite difficult question I think. At first look, it seems a to be a valid thinking that a secure partition that is handling an IRQ signal should be considered as an SPE ISR. However implementing this seems to be a nontrivial task. The code in the secure partitions is organised into a single thread, that executes a while loop, calls 'psa_wait()' in every iteration, and acts on the signals returned by it. The phenomenon we observed with your setup was the following: 1. When the Handler mode interrupt handler, that had lower priority than the PendSV reenabled interrupts after setting the signal, was interrupted by the PendSV handler. 2. PendSV handler scheduled the partition with the interrupt signal set, and did an exception return to thread mode. 3. The code of the Secure partition thread started executing, in Thread mode, but with the priority of the interrupt from the first point, as that interrupt handler was interrupted before it could do exception return to acknowledge the handling of the interrupt in the NVIC. 4. After the partition thread code called psa_wait again, the scheduler restored the context of the interrupt handler from the first point, that handler did an exception return, and everything is 'back to normal' Now, if I understand properly, your proposal is to make the conditions in point 3. to be mandatory for any scheduler implementation. To make this happen in TF-M, all the secure interrupts should have lower priority than the PendSV handler. This is necessary so that the above detailed behaviour is valid for all the interrupts. The problem with this is that the SPM has no control over which signal the code of the secure partition is going to execute. So in the current design a secure partition might decide to handle a service call signal (if there is any) instead of an IRQ signal, and that would be against our intention. We might be able to modify psa_wait to return only IRQ signals if there is any active, but that would be a violation of the PSA FF spec. Regards, Mate From: DeMars, Alan <ademars(a)ti.com> Sent: 12 November 2019 17:47 To: Mate Toth-Pal <Mate.Toth-Pal(a)arm.com> Cc: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Subject: RE: secure interrupt handlng in IPC mode You can CC the tf-m mailing list. From: Mate Toth-Pal [mailto:Mate.Toth-Pal@arm.com] Sent: Tuesday, November 12, 2019 8:02 AM To: DeMars, Alan Cc: Ken Liu (Arm Technology China) Subject: [EXTERNAL] RE: secure interrupt handlng in IPC mode Hi Alan Would it be OK to you if I cc the TF-M mailing list in my answer? Or if you would prefer that, I can move the 'Cooperative Scheduling Rules' document to the TF-M source (in the docs folder), and you can create a patch for it in gerrit. Thanks, Mate From: DeMars, Alan <mailto:ademars@ti.com> Sent: 11 November 2019 21:05 To: Mate Toth-Pal <mailto:Mate.Toth-Pal@arm.com> Cc: Ken Liu (Arm Technology China) <mailto:Ken.Liu@arm.com> Subject: secure interrupt handlng in IPC mode Hi Mate! I've been doing some thinking about the unexpected behavior we saw when a secure interrupt is configured with a lower priority than pendsv. I think the below statements in the Cooperative Scheduling Rules discussion: a. All of the SPE interrupts must have higher priority than NSPE interrupts d. A NSPE interrupt is not allowed to preempt SPE ISR must extend to the priority level of the SP as it services the interrupt while in thread mode. Otherwise the problem that these rules are meant to avoid can arise: the SPE is not completely restored to its IDLE state prior to a thread pre-empting NS interrupt occurring. So, rather than the behavior we witnessed being unexpected, I think it may have to be enforced. Is this correct thinking? Alan 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.

5 years, 7 months

3
2
0 0

Moving design documents from wiki into source folder with rst format

by Ken Liu (Arm Technology China)

Hi, There are some design documents created earlier is put at wiki. Since they are useful and going to be updated later, we need to move them into source folder with rst format. I have created an issue link for this: https://developer.trustedfirmware.org/T579 The list is here (from link: https://developer.trustedfirmware.org/w/tf_m/): Code Generation With Jinja2 (ongoing) Cooperative Scheduling Rules (ongoing) Inter-Processes Communication Non-secure Client Management (ongoing) Non-Secure Interrupt Handling (ongoing) Secure Partition Interrupt Handling (ongoing) Secure Storage Service Service IPC compatibility - Attestation Service IPC compatibility - SST Trusted Boot Trusted Firmware-m Isolation Level 2 Twin-cpu Uniform Secure Service Signature (ongoing) Some are picked up, the rest are welcome for picking up or comment! Please check the T579 for progress and provide comments in your interested topic - if you found there are some place needs to be updated in these 'old' docs, it is a good chance to update them during the moving. Thanks. /Ken

5 years, 7 months

1
0
0 0

Re: [TF-M] out of tree build

by Kevin Peng (Arm Technology China)

Hi Alan, I'm following on this and will get you updated on any progress. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Thursday, November 7, 2019 12:42 PM To: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Cc: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] out of tree build Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
1
0 0

Last call (for review) before merging linker script changes

by David Hu (Arm Technology China)

Hi all, I'm going to merge the following changes to common linker scripts to support dual-cpu platforms by the end of this week. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-linker-script%2… Those changes mainly focus on making it easier and more comfortable to configure Armv6-M/Armv7-M MPU on a dual-cpu platform. As the changes touch the common linker scripts, I'm sorry if it affects your tasks in hand. Please let me know if the merging concerns you or breaks any urgent task. Thank you. Best regards, Hu Ziji

5 years, 7 months

1
0
0 0

Re: [TF-M] extending common linker command file template

by Mate Toth-Pal

Hi Alan, Currently the only way to have custom content in the platform linker config files is to create a platform specific template in the platform directory, and refer to that in the platform CMake file instead of the common one. Although this might not be the best solution, as keeping the platform specific files up to date with the common linker config files can be an extra work. Did you have any specific solution in mind that could handle this situation? Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 14:17 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] extending common linker command file template We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] irqs "source" field

by Ken Liu (Arm Technology China)

Hi Alan, I think the "source" combines the usage of "number" and "name" since a tooling is needed eventually and tool can decide the assigned value is a number or name. Something like: /* Init Secure Partition - here is the pseudo code and does not exist in real sources */ p_irq_ctx = get_interrupt_ctx_by_source (p_manifest->source); /* Tool has converted the number or name into specified source index type */ init_interrupt(p_irq_ctx, THIS_SP); /* SP-IRQ binding is needed */ The 'source' here is just a keyword for tool searching in the platform resource descriptions and be converted into a program recognizable index so that runtime code could know the interrupt context and do something. The irq_number you proposed is direct which is good; but for the name, if we need to do extra operations instead of just know where the handler is, a looking up is still needed based on the irq name provided. That is just my opinion, you can try the email in FF spec for collecting feedbacks: arm.psa-feedback(a)arm.com BR /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Saturday, November 9, 2019 2:38 AM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] irqs "source" field I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi Reed, Thanks for the input. We name the dual-core/multi-core feature control option flag as `TFM_MULTI_CORE_TOPOLOGY` for a general model. But as Chris said, it would require additional work to design and support more complicated scenarios. Thus for the current particular patches for dual-core platform, I'd like to specify the topic a little as "dualcpu". Best regards, Hu Ziji -----Original Message----- From: Reed Hinkel <Reed.Hinkel(a)arm.com> Sent: Sunday, November 10, 2019 5:45 AM To: Christopher Brand <chris.brand(a)cypress.com>; Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology China) <David.Hu(a)arm.com> Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Makes sense! All the best! Reed On 11/8/19, 11:05 AM, "Christopher Brand" <chris.brand(a)cypress.com> wrote: I think that's actually an argument in favour of "dualcpu" for what we have now, because I suspect there would be significant work needed to support an additional core. Chris > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reed > Hinkel via TF-M > Sent: Friday, November 8, 2019 6:53 AM > To: Andrej Butok <andrey.butok(a)nxp.com>; David Hu (Arm Technology > China) <David.Hu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Change dual-core patch topic name "twincpu" to > "dualcpu" > > Just food for thought, but in the future some devices may have more than > two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m- > bounces(a)lists.trustedfirmware.org on behalf of tf- > m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David > Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the > same in the system. However, the two cores can be in different archs or > even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M > spec > > Could you please let me know if you have any concern about that change? > Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.t > rustedfirmware.org%2Fmailman%2Flistinfo%2Ftf- > m&data=02%7C01%7Candrey.butok%40nxp.com%7C9dc8588da6e2436e > 754508d76423ef30%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63 > 7087977806556698&sdata=it6Hfh2Vk9A5FUFudmNn206LYO9Wb8lOattG > %2FWsm2%2Bo%3D&reserved=0 > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

irqs "source" field

by DeMars, Alan

I think the PSA FF current definition of the "irqs" "source" attribute is needlessly opaque, confusing, and limiting. Why can't there simply be two attributes "irq_number" and "irq_name". "irq_number" corresponds to the CMSIS XYZ_IRQn convention in terms of its interpretation. It can be either a literal number or a manifest constant. "irq_name" is the symbolic name of the ISR as it appears in the user's vector table. That way there is no confusion regarding how they will be used. Alan

5 years, 7 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Jay Fallah

Hi Reed; Is there a minimum spec in terms of MCU such as M0 or M0+ or anything else for the RoT functionality MCU? Jay Fallah | Chief Technology Officer | NXM 888-416-6555 | mobile 647-927-9990 | ca.linkedin.com/in/jayfallah CONFIDENTIALITY NOTICE: This email message, including attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > On Nov 8, 2019, at 9:53 AM, Reed Hinkel via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. > > -Reed > > On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: > > OK. We use "dual", so it's better ;) > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M > Sent: Friday, November 8, 2019 9:16 AM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" > > Hi all, > > As you know, the current topic for dual-core patches is “twincpu”. > In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. > > Thus I’d like to propose to change the topic name to “dualcpu” to > > * Cover larger scope of dual-core topology/system. > * Align with the description in dual PE-based isolation section in TBSA-M spec > > Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 > Thank you. > > Best regards, > Hu Ziji > -- > 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 > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Reed Hinkel

Just food for thought, but in the future some devices may have more than two cores, but still with one core dedicated to RoT functions. -Reed On 11/8/19, 2:32 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- 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 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.

5 years, 7 months

1
0
0 0

Re: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu"

by Andrej Butok

OK. We use "dual", so it's better ;) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 8, 2019 9:16 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Change dual-core patch topic name "twincpu" to "dualcpu" Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 7 months

1
0
0 0

Change dual-core patch topic name "twincpu" to "dualcpu"

by David Hu (Arm Technology China)

Hi all, As you know, the current topic for dual-core patches is “twincpu”. In my very own opinion, keyword “twin” implies that the two cores are the same in the system. However, the two cores can be in different archs or even heterogeneous in a dual-core system. Thus I’d like to propose to change the topic name to “dualcpu” to * Cover larger scope of dual-core topology/system. * Align with the description in dual PE-based isolation section in TBSA-M spec Could you please let me know if you have any concern about that change? Any feedback or suggestion is welcome. 😊 Thank you. Best regards, Hu Ziji

5 years, 7 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

Trying again after renaming tfm_parse_manifest_list.py to tfm_parse_manifest_list.txt so it wouldn't get deleted. --- With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] out of tree build

by DeMars, Alan

With the attached modified secure_fw/CMakeLists.txt and tools/tfm_parse_manifest_list.py files, I am able to redirect the generated files using the following command line: python3 <full_path_to_your>/tfm_parse_manifest_list.py <full_path_to_your>/tfm_manifest_list.yaml <full_path_to_your>/tfm_generated_file_list.yaml <full_path_to_your>/<build_dir> And then build the ConfigCoreIPC artifacts within <your_build_dir> using the following cmake line: cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../configs/ConfigCoreIPC.cmake` -DREMOTE_GEN_DIR=<full_path_to_your><build_dir> -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ The changes to tfm_parse_manifest_list.py are backward compatible with the standard usage. Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Monday, November 4, 2019 4:36 PM To: Abhishek Pandit; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] Re: [TF-M] out of tree build Abishek, Yes, we have modified tfm_gen.py and tfm_parse_manifest_list.py to support redirecting the destination of the generated template files into a command line provided destination build directory. A corresponding change to our platform's platform/ext/xyz.cmake file was also required to add the path to the root of the build directory to the embedded_include_directories() list as well as the paths to the generated linker command files. I was not planning to provide these changes as a patch for review as I am very unsure of the applicability of this to other platforms. Also, I was fairly certain that given my very poor understanding of the CMake build system, my approach to the problem was not utilizing features present in CMake that would make the job simpler and more extensible. Since the topic came up at the conference and you already seemed willing to address the out-of-tree build problem that the templates lead to, I assumed you folks would find a simple and elegant solution that would save me the embarrassment of exposing my lack of CMake expertise. Alan -----Original Message----- From: Abhishek Pandit [mailto:Abhishek.Pandit@arm.com] Sent: Monday, November 4, 2019 3:08 PM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org Subject: [EXTERNAL] RE: out of tree build Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Patches to share common code between TF-M ITS and SST services

by Jamie Fox

Hi all, The ITS and SST partitions in TF-M share a common implementation for the backend FS and flash layers, but currently this code is duplicated between the two partitions, increasing overall code size. To fix this, it was previously proposed to keep the common code in only the ITS partition, with SST making service requests to ITS to complete FS and flash operations. The patches to implement this are now available for review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2425 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2426 The first patch refactors the FS and flash code in ITS to support multiple contexts, with multiple flash devices. The second refactors SST to make requests to ITS instead of calling the FS code directly, and modifies ITS to handle requests that originate from SST with SST's FS context and flash device. This is a fairly significant change to the architecture of the two services, so feedback would be particularly appreciated. Kind regards, Jamie

5 years, 7 months

1
0
0 0

Re: [TF-M] out of tree build

by Abhishek Pandit

Hi Alan, Not sure if I remember the exact detail from the workshop last week, but did you mention that you have a prototype for this? If so, are you planning to push a patch for review? Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 November 2019 16:29 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] out of tree build Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

Re: [TF-M] Weak symbols

by Grosen, Mark

Before deciding and documenting this, could we review and decide on the overall project's applicable standards? I am guessing that "more strict requirements" might hint at things like MISRAC. I would rather see a general framework for how coding standards are either inherited or defined than one-off choices. There are other questionable coding practices in the current code base that would have trouble with MISRAC. That said, if we will adopt MISRAC, we can also adopt deviations and waivers that allow for (limited) uses of general violations. A well-documented, reviewed and approved deviation is normal practice in most projects trying to adhere to formal quality standards. Mark -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, November 1, 2019 7:04 AM To: Abhishek Pandit; Christopher Brand; tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Weak symbols Hi, In my own words, :) it is one of the steps to be compliant with some coding guidelines with more strict requirements. We are updating the doc to specify the details. Best regards, Hi Ziji ________________________________ From: Abhishek Pandit <Abhishek.Pandit(a)arm.com> Sent: Friday, November 1, 2019 6:59:32 PM To: David Hu (Arm Technology China) <David.Hu(a)arm.com>; Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: RE: Weak symbols Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

out of tree build

by DeMars, Alan

Please modify the template generators to support out of tree build, and modify the CMake files to add the necessary include paths so that the files that include the template-generated files can find them. Alan

5 years, 7 months

1
0
0 0

Re: [TF-M] Weak symbols

by Abhishek Pandit

Hi David, As this thread is specifically for weak symbols, it would be helpful to provide some more reasoning behind the new guidance. Could be a good opportunity to discuss further as well. Thanks, Abhishek -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: 01 November 2019 10:24 To: Christopher Brand <chris.brand(a)cypress.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Weak symbols Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

2
1
0 0

extending common linker command file template

by DeMars, Alan

We've had to add two memory regions and section placements to the "tfm_common_s.ld.template". Rather than polluting this "common" template, is there a way to extend the functionality so that platform-specific content can be included in the generated linker command file? Alan

5 years, 7 months

1
0
0 0

Re: [TF-M] Weak symbols

by David Hu (Arm Technology China)

Hi Chris, Sorry for the inconvenience. The discussion to figure out the new guidance did cost some time. The initial conclusion is that the weak symbol/function should be avoided in new code added to TF-M. Platform support code may use weak symbols as an exception to make platform specific implementation flexible. The code guidance will be updated soon to address this issue formally. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christopher Brand via TF-M Sent: Wednesday, October 30, 2019 7:50 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Weak symbols Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by DeMars, Alan

After further analysis, I found this to be true: If the secure interrupt has a priority lower than the secure pendsv interrupt, then the associated SP code will run in thread mode at the exception priority level of the secure interrupt. If the priority of the secure interrupt is equal to or greater than the secure pendsv interrupt then associated the SP code will run in thread mode with NO exception priority level. Alan -----Original Message----- From: DeMars, Alan Sent: Tuesday, October 29, 2019 8:54 AM To: 'Mate Toth-Pal' Cc: 'tf-m(a)lists.trustedfirmware.org' Subject: RE: SP thread priority when servicing secure interrupts Mate, I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60. I'll attempt to provide a procedure for reproducing my results. In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Weak symbols

by Christopher Brand

Hi, There are a couple of code reviews that I've been involved with that seem to be being held up due to the use of weak symbols. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212 There seems to be a feeling among some reviewers that weak symbols are discouraged in TF-M, due to them not being in the C standard. There's no mention of weak symbols in docs/coding_guide.rst. There is a brief mention in docs/user_guides/tfm_secure_irq_handling.rst: In Library model a function with the name derived from the value of the ``line_num`` or ``line_name`` property is generated. This function will be put in the vector table by the linker (as the handlers in the startup assembly are defined as weak symbols). The code generated for this function will forward the call to the function with the name of the value of the ``signal`` property post-fixed with ``_isr``. So that document explicitly states that weak symbols will be used in TF-M. TFM already uses weak symbols fairly extensively. A quick grep shows two instances under "interface": interface/src/tfm_ns_interface.c: __attribute__((weak)) int32_t tfm_ns_interface_dispatch(veneer_fn fn, [...] __attribute__((weak)) enum tfm_status_e tfm_ns_interface_init(void) and several hundred under "platform": $ grep -ri weak platform/ --exclude=tfm_mbedcrypto_config.h --exclude=cmsis_\*.h | wc 747 5902 109938 Looking at Phabricator, the only mention of weak symbols I can find is in https://developer.trustedfirmware.org/T363 and https://developer.trustedfirmware.org/T198, both of which explicitly state that new weak functions will be added, and https://developer.trustedfirmware.org/T463, which doesn't take a position either way. Weak symbols have been discussed a little on the mailing list in the thread at https://lists.trustedfirmware.org/pipermail/tf-m/2019-October/000430.html but not very extensively. My feeling is that it wouldn't be unreasonable to decide that weak symbols should be discouraged, and it might even make sense for somebody to take on the task of removing them from TF-M, although that looks like a significant amount of work. Of course it would be nice to see that documented, presumably in docs/coding_guide.rst (and presumably corresponding changes to docs/user_guides/tfm_secure_irq_handling.rst and tasks T198 and T463). As things stand right now, they do seem to be an accepted mechanism within TF-M, and worrying about adding a handful more to the nearly 750 we have now seems unreasonable - if we do decide at some point not to use weak symbols, the work involved in removing 760 or even 800 Is not significantly more than would be needed now. The code reviews I cited have been out there for 6 weeks now. It would be really nice to find a way forward... Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

1
0
0 0

Searching the list archives

by Christopher Brand

Is there a "search" interface for this mailing list somewhere? The archive page at https://lists.trustedfirmware.org/pipermail/tf-m/ doesn't seem to provide one (it's not too onerous at the moment to download the 12 gzipped files and search them, but that's going to get worse as time goes by). Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 7 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by DeMars, Alan

Mate, I'm using the IPC model. My secure interrupt has priority 0xe0, whereas the pendSV interrupt has priority 0x60. I'll attempt to provide a procedure for reproducing my results. In the meantime, is there a doubt-free way to determine the execution priority while the processor is in thread mode? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Tuesday, October 29, 2019 5:50 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] SP thread priority when servicing secure interrupts Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

Re: [TF-M] SP thread priority when servicing secure interrupts

by Mate Toth-Pal

Hi Alan, The expected behaviour depends on the Model used in the TF-M. Library model: The generated interrupt handler runs in Handler mode, and after doing an SVC, it starts executing the handler defined in the SP in thread mode. At that point the interrupt handler hadn't returned, so the interrupt is still active in the NVIC. This means that the execution priority of the CPU is equal to the interrupt's priority, even if the processor is executing in thread mode. At the end of the execution of the SP interrupt handler, an SVC is executed, which then return to the context of the generated interrupt handler. And only at this point does the interrupt handler return, and can a pending interrupt with lower priority be active. IPC model: The generated interrupt handler runs at the interrupt’s assigned priority, sets a signal for the partition that should handle the interrupt, and then returns. So the interrupt is cleared in the NVIC. After this, the secure scheduler can schedule the handling partition (the scheduling happens in a PendSV handler), and the signal handler runs in thread mode. In this case the priority of the thread mode is 256 (no priority boosting, and no active exceptions). So the execution can be interrupted. The generated stub is not run again, until the interrupt gets triggered again. If you still find the behaviour of the system unexpected, could you please share some more information about the environment and sequence of steps for reproducing the behaviour? Best would be if you could reproduce the behaviour with one of the platforms supported by the upstream TF-M, and share your patch, so Others could have a look at it in the debugger as well. Thanks, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 29 October 2019 01:52 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] SP thread priority when servicing secure interrupts It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 7 months

1
0
0 0

SP thread priority when servicing secure interrupts

by DeMars, Alan

It appears that when a SP is servicing a manifest-specified secure interrupt configured with a priority equal to or lower than the pendsv interrupt, the processor is operating at the priority of the pendsv interrupt. While the SP is servicing the secure interrupt's signal (ie: in thread mode), If another interrupt is triggered of the same priority or lower than the pendsv, that new interrupt is not immediately vectored to. Instead, it is vectored to AFTER the secure interrupt's stub function (generated by the template) returns. Is this true and expected behavior? Unless BASEPRI is set to some non-zero value, I thought the processor was always running with no exception priority while in thread mode. Alan

5 years, 7 months

1
0
0 0

Dual core boot design document review

by Christopher Brand

Hi, Back in March, I wrote the dual-core design document at https://developer.trustedfirmware.org/w/tf_m/design/twin-cpu/bootloader/ It was discussed on the mailing list in a thread that starts at https://lists.trustedfirmware.org/pipermail/tf-m/2019-March/000088.html Since then, TF-M has defined a process for design reviews, and it would be nice to get this design document into the docs/design directory, particularly as the implementation of the design is already in the codebase. Given that there has already been discussion on the mailing list, I've gone ahead and created a review in Gerrit: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2384 I also added all the people who contributed to that thread as reviewers. Please feel free to add yourself as a reviewer. Also, comments on whether this is the right process to follow for design documentation in this transitional state would be useful. Thanks, Chris This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 8 months

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Mate Toth-Pal

Hi Alan, Andrej is right about PSA certification, for that you don't need to pass the regression test suite. However for submitting a change to the upstream master branch on https://www.trustedfirmware.org/ it is a requirement to pass those tests. The peripherals defined in the tfm_peripherals_def.h files are the peripherals that are mentioned in the 'mmio_regions' node in the partition manifest yaml files. It is a requirement that a macro is defined with this name that is substituted to a pointer type value. For more details see platform\readme.rst, chapter 'platformext/target/tfm_peripherals_def.h'. The type 'tfm_spm_partition_platform_data_t' is defined by the platform implementation, so TF-M core has no knowledge about the content of an object of type 'tfm_spm_partition_platform_data_t', and doesn't use it. The pointer is only considered by it as a token, that is passed to the platform HAL functions. This means that if the platform needs to do nothing related to the peripherals in the HAL functions either because - no isolation is needed to be configured for that peripheral - the peripheral doesn't exist, and the functionality is emulated (1) it is OK to define the value of the macro to be NULL (Just as it is done in platform/ext/target/musca_a/tfm_peripherals_def.h). The TFM_PERIPHERAL_FPGA_IO is used by the core test, to access button state and to blink leds. For the Musca-A platform these functionalities are emulated in the file platform/ext/target/musca_a/plat_test.c TFM_PERIPHERAL_TIMER0 is used by the IRQ tests. The upstreamed platforms all support some kind of timer, so there is a real implementation for all the platforms. (platform/ext/target/musca_a/plat_test.c) If it is not possible to create working implementations for the interfaces in platform/include/tfm_plat_test.h, then it is possible to disable the peripheral access and irq tests, by adding the following lines to the platform cmake file: set(TFM_ENABLE_PERIPH_ACCESS_TEST Off) set(TFM_ENABLE_IRQ_TEST Off) Please note, that even in this case TFM_PERIPHERAL_FPGA_IO and TFM_PERIPHERAL_TIMER0 are still need to be defined (NULL is ok), and the plat_test interface functions also need to have at least an empty implementation. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 24 October 2019 08:39 To: DeMars, Alan <ademars(a)ti.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] IPC Regressions reference platform specific resources Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- 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

5 years, 8 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi, The process of contributing to TF-M patch is updated now: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1007/ We can get an updated version after reviewing. Regards, Summer On 10/23/19, 7:55 PM, "Shebu Varghese Kuriakose via TF-M" <tf-m(a)lists.trustedfirmware.org> wrote: Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Align manifest to PSA FF 1.0.0

by Edison Ai (Arm Technology China)

Hi all, I had created a set of patches to align the manifest to PSA FF 1.0.0: https://review.trustedfirmware.org/#/q/topic:manifest_alignment+(status:ope…. The manifest is the basics that are related to almost every module. So please help to review them as far as possible. Thanks, Edison

5 years, 8 months

1
0
0 0

Re: [TF-M] IPC Regressions reference platform specific resources

by Andrej Butok

Hi Alan > I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. Regression tests are only to check if your TFM port is correct (not for certification). You should to demonstrate a successful log from the PSA Test Suite, but only for the "PSA Certified Functional API". For the PSA Certified Level 1, it is not required. Best regards, Andrej Butok NXP Semiconductors -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Wednesday, October 23, 2019 5:20 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] IPC Regressions reference platform specific resources I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

5 years, 8 months

1
0
0 0

IPC Regressions reference platform specific resources

by DeMars, Alan

I'm attempting to build the ConfigRegressionIPC image and have run into the issue that some of the tests rely on device specific resources (TFM_PERIPHERAL_TIMER0 and TFM_PERIPHERAL_FPGA_IO). I assume that to obtain any kind of TF-M compliance certification for our platform, I will be required to demonstrate successful execution of these regression tests. If that is so, how should I proceed to resolve this conflict? Alan

5 years, 8 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Shebu Varghese Kuriakose

Hi Alan, 'Create Task' is the correct option to use. You can also add 'Trusted Firmware M' as the project name in the Tags field in the task. Looks like contributing.rst can do with a few updates/corrections. Regards, Shebu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: Monday, October 21, 2019 7:37 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] contributing to the TF-M project I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] contributing to the TF-M project

by Summer Qin (Arm Technology China)

Hi Alan, Thanks for reporting this issue. Yes, the "Create Task" in https://developer.trustedfirmware.org/maniphest is the place you can use. Just create a task, add the tag "Trusted Firmware M" and others you can set as you want or keep them as default. And please add this task link under your commit as comments, please add the test env and result as well if you have. This part needs to be updated, and we will push a patch to fix it ASAP. Regards, Summer On 10/22/19, 2:37 AM, "TF-M on behalf of DeMars, Alan via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

contributing to the TF-M project

by DeMars, Alan

I am trying to follow the instructions provided here: https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/contributi… But I'm stumbling on the very first step: - Create an issue in http://issues.trustedfirmware.org to keep others informed about your ongoing work. When I log into the sight, I have not been able to find how to create an issue. I see links for "Create Task" and "Create Project" but nothing for "Create Issue". What am I doing wrong? Alan

5 years, 8 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Gyorgy Szing

Hi, We need to keep an eye on some factors which the current prototype ignores. Some that come to my mind: 1. which component shall be the owner of sw dependency info? (Documentation, cmake, something else?). 2. how does the solution scale? (i.e. be able to handle platform specific dependencies). 3. how we handle build configuration specific dependencies? (i.e. if I don't build a service then some dependency is not needed). 4. As Minos mentioned some environment verification is already done by CMake. Is it worth to extract all dependency info (tooling + SW) into a dedicated place? /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: 21 October 2019 16:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Minos Galanakis

Hi, Making CMAKE able to output the dependencies it is expecting is the quickest path, but it is only able to resolve a subset of the requirements captured by the documenation. .<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> For example the cmake version itself, or tools like srec_cat used to produce MUSCA binaries. There are certain dependencies that are provided by other means ( package managers ) . So while I agree that it looks quite odd, it is hierarchically the origin of the information we are trying to capture. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Kumar Gala via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 21 October 2019 15:25 To: Devaraj Ranganna <Devaraj.Ranganna(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Python script to generate tf-m dependencies in JSON format This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] Python script to generate tf-m dependencies in JSON format

by Kumar Gala

This feels backwards, parsing rst to determine build steps, dependancies doesn’t feel correct. I think it would be better to codify the build steps in scripts of CMake, etc than reference those in the .rst instead. - k > On Oct 21, 2019, at 9:03 AM, Devaraj Ranganna via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi, > > Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). > > The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. > > If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following > > > * Use a reStructuredText grid table to define dependencies > * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script > > I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. > > This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). > > Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. > > Thanks, > Dev > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Python script to generate tf-m dependencies in JSON format

by Devaraj Ranganna

Hi, Currently tf-m dependencies are only listed in documentation file (docs/user_guides/tfm_build_instruction.rst) and there is no option to programmatically retrieve it. In order to integrate tf-m into non-secure side RTOSes, it is very essential to be able build tf-m automatically without manual intervention (may be as part of CI). The tf-m CI build system uses fixed values for dependencies and it is the responsibility of developers who update the dependencies to update the documentation and the CI build system. If non-secure side RTOSes use fix values for tf-m dependencies then either build or regression tests may fail when tf-m updates dependencies. In order avoid this issue, I’m proposing the following * Use a reStructuredText grid table to define dependencies * Python script to produce a json file in the root directory when invoked as standalone script or to return a json string when imported into another python script I’ve created a patch set (https://review.trustedfirmware.org/c/trusted-firmware-m/+/2333) with above changes. I’d appreciate your inputs/feedback on this proposal. This will also ensure that dependencies are captured in one place (docs/user_guides/tfm_build_instruction.rst). Additionally, have another python script as “post-checkout” git hook which can parse dependencies in JSON format and clone them automatically when tf-m repository is cloned or when switching from master to feature branch and vice versa. Thanks, Dev 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.

5 years, 8 months

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Gyorgy Szing

Hi Kumar, there are some internal discussions on how "build system provisioning" and dependency handling can be enhanced. For now the most convenient might be to use the CI configuration files available here: https://git.trustedfirmware.org/ci/dockerfiles.git/tree/xenial-amd64-tf-m-b… /George -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: 18 October 2019 15:53 To: David Vincze <David.Vincze(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] New tool requirement in TF-M My point was that having them in a file that you an pass to pip install -r would be a useful thing and make setup easier for the user. - k > On Oct 18, 2019, at 2:59 AM, David Vincze <David.Vincze(a)arm.com> wrote: > > Hi Kumar, > > We also have one in TF-M: > https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/4/doc > s/user_guides/tfm_sw_requirement.rst > > David > > -----Original Message----- > From: Kumar Gala <kumar.gala(a)linaro.org> > Sent: 17 October 2019 15:52 > To: David Vincze <David.Vincze(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] New tool requirement in TF-M > > Might be good to have some kinda of requirements.txt that lists out all python modules needed. > > In zephyr there is: > > https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requi > rements.txt > > You can see the install/setup guide details here: > > https://docs.zephyrproject.org/latest/getting_started/index.html#insta > ll-python-dependencies > > - k > >> On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi All, >> >> We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. >> It adds the cbor 1.0.0 Python package to the list of tools that are >> required to build TF-M. Once it is merged, this package has to be >> installed in the build environment, otherwise the builds will fail. >> The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). >> >> Regards, >> David Vincze >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] New tool requirement in TF-M

by Kumar Gala

Might be good to have some kinda of requirements.txt that lists out all python modules needed. In zephyr there is: https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requiremen… You can see the install/setup guide details here: https://docs.zephyrproject.org/latest/getting_started/index.html#install-py… - k > On Oct 17, 2019, at 5:20 AM, David Vincze via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. > It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package > has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the > following command: pip3 install --user cbor > (or manually after downloading the package from here: https://pypi.org/project/cbor/). > > Regards, > David Vincze > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

2
2
0 0

New tool requirement in TF-M

by David Vincze

Hi All, We will merge this patch (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/) to TF-M during the day. It adds the cbor 1.0.0 Python package to the list of tools that are required to build TF-M. Once it is merged, this package has to be installed in the build environment, otherwise the builds will fail. The cbor package can be installed with the following command: pip3 install --user cbor (or manually after downloading the package from here: https://pypi.org/project/cbor/). Regards, David Vincze

5 years, 8 months

1
0
0 0

Modifying the bootloader - runtime sw interface

by David Vincze

Hi all, I have 3 patches on review (/2149<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2149/>, /2148<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2148/>, /2147<https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/2147/>) that will change the interface between MCUBoot and the runtime SW. Currently the bootloader passes the measured boot status data to the attestation service through a shared memory area as individual claims (in TLV format). With these changes the boot status data will be encoded to CBOR format at build time and will be added to the image manifest during the image signing process. The bootloader will share this data the same way as before (as a new type of TLV), however the attestation service will have to handle this data differently as it's already CBOR encoded. This can cause the attestation tests to fail if an older MCUBoot image has been used with a newer build of the secure image or vice versa. To address this issuse / provide backward compatibility the new 'ATTEST_BOOT_INTERFACE' variable will be introduced in the build system (in one of the above patches) to be able to get back the old behavior. For this the 'ATTEST_BOOT_INTERFACE' variable has to be set to "INDIVIDUAL_CLAIMS" in the CMake configuration step: "cmake -G"Unix Makefiles" -DPROJ_CONFIG=../configs/ConfigRegression.cmake -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM -DATTEST_BOOT_INTERFACE=INDIVIDUAL_CLAIMS ../" The old behavior will be retained for a while, however we have an intention to remove it entirely from the code in the future. Please let me know if you have any questions or concerns. I'd also welcome any feedback on the reviews. Best regards, David Vincze

5 years, 8 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by Miklos Balint

Hi Alan, Thanks for the suggestion and the clarifications provided to Ken. During the course of the mail thread, you raised a design principle issue as well as implementation details, and I'll try to address the design principle question later as that is an important topic, but first allow me to touch on one implementation detail for this specific feature: While convenient in GCC, weak symbols are not defined by the C99 standard and their use and syntax is therefore compiler-specific, which is not good from a portability point of view and may cause difficulties with different toolchains. In my opinion a preprocessor-based solution e.g. in the switch-case of the generic SVC handler would be more portable. Could you check the feasibility of that approach? The default expansion could be empty for platforms that do not implement platform-specific SVC handlers, and an arbitrary list of additional case statements for SVC numbers implemented by the platform code for your platform. Please let us know your thoughts, Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 10 October 2019 15:45 To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to > support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() >> to support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, >>> flag), SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of >>> user buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' >>> <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> Alan >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

2
1
0 0

TF-M's Documentation website is live

by Minos Galanakis

Hi all, TF-M's documentation has now launched. The project is using Sphinx to render the documents into HTML which can be accessed via the link bellow: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu… The main website has been updated with shortcuts to the new location which can be accessed by navigating at https://www.trustedfirmware.org/ -> Documentation -> Docs > TF-M Thanks, Minos

5 years, 8 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I agree with the approach you suggest. I planned to put the non-weak implementation in the same directory as spm_hal.c and target_cfg.c, etc. I’ll name the file “platform_svc_hal.c“ to reflect the common/platform_svc.c it is related to. Alan > On Oct 9, 2019, at 9:54 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Well, I was trying to see the whole picture, but looks like they are platform specific and some part is not public. > > Back to focus the SVC proposal itself, the weak function looks well, can you considerate these: > > - Put the implementation of the weak function under: platform/ext/common/platform_svc.c? > > Before this, we need to: > > - Reserve a range for platform SVC, and let platform define it by themselves. > > The reason is: > > - These extended SVCs are from specific vendors, which means from specific platforms. So I think it is reasonable to put it into platform scope. Or do you think it is a common case out of platform scope? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:38 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services > > I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. > > My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. > > Alan > >> On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. >> >> I am curious about the requirements you are facing so I am eager to see the changes. >> >> Thanks. >> >> /Ken >> >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 12:07 PM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> >> Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >> support custom services >> >> Ken, >> >> If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. >> >> Alan >> >>>> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >>> >>> Hi Alan, >>> >>> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >>> >>> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >>> >>> While: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >>> >>> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >>> >>> So the in the handler there would be permission checking: >>> >>> case SVC_ACCESS_RESOUCE: >>> If (spm_check_address_ownership(addr, CURRENT_SP)) >>> ret = do_access(addr, data, sz, flags); >>> >>> And the IIC_WRITE was implemented as: >>> I2c_write(addr, value) { *host_reg_slave_addr = addr; >>> *host_reg_slave_data = value; *host_reg_control_go = 1; } >>> >>> Now turned into: >>> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), >>> SVC_ACCESS(host_reg_slave_data, value, flag), >>> SVC_ACCESS(host_reg_control_go, 1, flag)} >>> >>> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >>> >>> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 11:14 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >>> >>> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >>> >>> Alan >>> >>> -----Original Message----- >>> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >>> Sent: Wednesday, October 9, 2019 7:47 PM >>> To: DeMars, Alan >>> Cc: nd >>> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >>> custom services >>> >>> Hi Alan, >>> >>> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >>> >>> The proposed way would be: >>> TFM_SVC_ACCESS_RESOURCE >>> >>> And the parameter would be: >>> >>> uintptr_t resource_addr /* The address you want to access */ void >>> *p_user_buffer /* User-provided buffer */ size_t size /* size of user >>> buffer */ uint32_t flags /* Flags, like read/write */ >>> >>> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: DeMars, Alan <ademars(a)ti.com> >>> Sent: Thursday, October 10, 2019 10:27 AM >>> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >>> Cc: nd <nd(a)arm.com> >>> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> Ken, >>> >>> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >>> >>> Alan >>> >>> -----Original Message----- >>> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >>> Of Ken Liu (Arm Technology China) via TF-M >>> Sent: Wednesday, October 9, 2019 7:04 PM >>> To: tf-m(a)lists.trustedfirmware.org >>> Cc: nd >>> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >>> support custom services >>> >>> Hi Alan, >>> >>> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >>> >>> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >>> >>> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >>> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >>> >>> Thanks. >>> >>> /Ken >>> >>> -----Original Message----- >>> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >>> DeMars, Alan via TF-M >>> Sent: Thursday, October 10, 2019 4:38 AM >>> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> >>> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >>> services >>> >>> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >>> >>> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >>> >>> default: >>> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >>> >>> __attribute__((weak)) >>> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >>> LOG_MSG("Unknown SVC number requested!"); >>> return PSA_ERROR_GENERIC_ERROR; } >>> >>> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >>> >>> Is this OK? >>> >>> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >>> >>> Alan >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >>> -- >>> TF-M mailing list >>> TF-M(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

1
0
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

I think I’ve already provided the changes I propose. The ‘default’ case will be for the SVC handler to invoke the provided weak defined function as shown. If a non-weak version of the function exists during the link process, the non-weak implementation will be invoked instead. My intent is to provide a proprietary non-weak implementation of “custom_ipc_svc_handlers()”. Alan > On Oct 9, 2019, at 9:22 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > The example here is the worst case for APP RoT accessing the peripherals, so you are right with the latency issue in this case. In most cases, the service manipulating the secure hardware can be PSA RoT so they access the peripheral directly. > > I am curious about the requirements you are facing so I am eager to see the changes. > > Thanks. > > /Ken > > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 12:07 PM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> > Subject: Re: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > Ken, > > If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. > > Alan > >> On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Alan, >> >> The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): >> >> I2c_write (I2C_ADDR, SLAVE_ADDR, value); >> >> While: >> I2c_write(addr, value) { *host_reg_slave_addr = addr; >> *host_reg_slave_data = value; *host_reg_control_go = 1; } >> >> The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. >> >> The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. >> >> So the in the handler there would be permission checking: >> >> case SVC_ACCESS_RESOUCE: >> If (spm_check_address_ownership(addr, CURRENT_SP)) >> ret = do_access(addr, data, sz, flags); >> >> And the IIC_WRITE was implemented as: >> I2c_write(addr, value) { *host_reg_slave_addr = addr; >> *host_reg_slave_data = value; *host_reg_control_go = 1; } >> >> Now turned into: >> I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), >> SVC_ACCESS(host_reg_slave_data, value, flag), >> SVC_ACCESS(host_reg_control_go, 1, flag)} >> >> But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. >> >> If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 11:14 AM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >> services >> >> I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? >> >> I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. >> >> Alan >> >> -----Original Message----- >> From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] >> Sent: Wednesday, October 9, 2019 7:47 PM >> To: DeMars, Alan >> Cc: nd >> Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support >> custom services >> >> Hi Alan, >> >> Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? >> >> The proposed way would be: >> TFM_SVC_ACCESS_RESOURCE >> >> And the parameter would be: >> >> uintptr_t resource_addr /* The address you want to access */ void >> *p_user_buffer /* User-provided buffer */ size_t size /* size of user >> buffer */ uint32_t flags /* Flags, like read/write */ >> >> Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: DeMars, Alan <ademars(a)ti.com> >> Sent: Thursday, October 10, 2019 10:27 AM >> To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> >> Cc: nd <nd(a)arm.com> >> Subject: RE: augmenting the SVC_Handler_IPC() to support custom >> services >> >> Ken, >> >> There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. >> >> Alan >> >> -----Original Message----- >> From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf >> Of Ken Liu (Arm Technology China) via TF-M >> Sent: Wednesday, October 9, 2019 7:04 PM >> To: tf-m(a)lists.trustedfirmware.org >> Cc: nd >> Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to >> support custom services >> >> Hi Alan, >> >> Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. >> >> From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. >> >> Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. >> We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. >> >> Thanks. >> >> /Ken >> >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> DeMars, Alan via TF-M >> Sent: Thursday, October 10, 2019 4:38 AM >> To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> >> Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom >> services >> >> I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). >> >> I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: >> >> default: >> return (custom_ipc_svc_handlers(svc_num, ctx, lr)); >> >> __attribute__((weak)) >> int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { >> LOG_MSG("Unknown SVC number requested!"); >> return PSA_ERROR_GENERIC_ERROR; } >> >> This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. >> >> Is this OK? >> >> Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. >> >> Alan >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

2
1
0 0

Re: [TF-M] [EXTERNAL] Re: augmenting the SVC_Handler_IPC() to support custom services

by DeMars, Alan

Ken, If I understand the proposal, I’m afraid the latency and overhead associated with every peripheral register access (read or write) would be completely unacceptable for our requirements. Alan > On Oct 9, 2019, at 8:47 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Alan, > > The secure service is allowed to access some peripherals they want (introduce them in the manifest file), which means if you want to access a I2C device you can just (ALL CODE HERE IS PSEUDO CODE AND IS NOT REAL): > > I2c_write (I2C_ADDR, SLAVE_ADDR, value); > > While: > I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } > > The reason of providing the SVC interface is because the APP RoT Service may want to access some registers but they could not because those registers may be set as privileged. > > The secure service needs to handle the hardware driver in their own domain instead of putting all drivers into core. > > So the in the handler there would be permission checking: > > case SVC_ACCESS_RESOUCE: > If (spm_check_address_ownership(addr, CURRENT_SP)) > ret = do_access(addr, data, sz, flags); > > And the IIC_WRITE was implemented as: > I2c_write(addr, value) { *host_reg_slave_addr = addr; *host_reg_slave_data = value; *host_reg_control_go = 1; } > > Now turned into: > I2c_write(addr, value) { SVC_ACCESS(host_reg_slave_addr, addr, flag), SVC_ACCESS(host_reg_slave_data, value, flag), SVC_ACCESS(host_reg_control_go, 1, flag)} > > But if you are saying that, there are some even more complex logics for example some I2C devices can be accessed under privileged only while all the rest can be accessed freely, yes, the interface I proposed is limited. In this case you can introduce the customized logic into core with some new SVC. > > If the previous line is your case, please go on with the modification in the first mail, the modification looks okay, and let's discuss base on the patches. > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 11:14 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: RE: augmenting the SVC_Handler_IPC() to support custom services > > I think the TFM_SVC_ACCESS_RESOURCE proposal is too limiting. What if (as is true in our case) there is a complex sequence of writes/reads and careful timing that must be performed to access a resource? > > I'm not sure why TF-M is wanting/needing to limit what I can do with the secure SVC handler. You've claimed ownership of the standard mechanism for entering secure privileged mode and are more-or-less dictating the set of APIs that can be provided/implemented with this standard mechanism. > > Alan > > -----Original Message----- > From: Ken Liu (Arm Technology China) [mailto:Ken.Liu@arm.com] > Sent: Wednesday, October 9, 2019 7:47 PM > To: DeMars, Alan > Cc: nd > Subject: [EXTERNAL] RE: augmenting the SVC_Handler_IPC() to support custom services > > Hi Alan, > > Since the peripheral accessing functionality is missing now, the way you mentioned would be the only choice. We got a plan to implement some function for accessing privileged resources, can you promote your function into a common implementation so that we could re-use your code for future development? > > The proposed way would be: > TFM_SVC_ACCESS_RESOURCE > > And the parameter would be: > > uintptr_t resource_addr /* The address you want to access */ void *p_user_buffer /* User-provided buffer */ size_t size /* size of user buffer */ uint32_t flags /* Flags, like read/write */ > > Or you can define a customized structure for the parameter (if you put more than 4 parameters svc_handler need to dispatch customized aapcs which makes life hard) when you are accessing some serial connected devices? > > Thanks. > > /Ken > > -----Original Message----- > From: DeMars, Alan <ademars(a)ti.com> > Sent: Thursday, October 10, 2019 10:27 AM > To: Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com> > Subject: RE: augmenting the SVC_Handler_IPC() to support custom services > > Ken, > > There are certain resources that can only be interrogated in secure privilege mode on our platform. Nonetheless, unprivileged SP code (ie level 2) will need to be informed of content available in those privileged resources. As TFM has claimed ownership of the SVC handler, I need to extend that SVC handler to provide the functionality our SP services require. > > Alan > > -----Original Message----- > From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu (Arm Technology China) via TF-M > Sent: Wednesday, October 9, 2019 7:04 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd > Subject: [EXTERNAL] Re: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > Hi Alan, > > Looks like you are working under IPC model, and you need something to do in core/spm. If you can provide more details then it will be great. > > From the code change itself, it has no problem, I am planning a re-structure on this part so if there are issues we can fix them later one. But when we look at the service programming model, we need to know the newly added SVC function is really an 'spm/core' function. > > Calling an SVC typically happen when we want to access privileged resource (registers or restricted memory), or some other customized behaviours. > We need to be careful when we adding core functionalities because TF-M IPC model maintains a very small core and provide only necessary core functionalities (scheduling, spm). There are PSA RoT Services who has a higher privileged level already, and secure partition can access the peripheral they want. > > Thanks. > > /Ken > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M > Sent: Thursday, October 10, 2019 4:38 AM > To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] augmenting the SVC_Handler_IPC() to support custom services > > I need to add custom SPM APIs to augment our SP services. Consequently, I need to extend the set of SVCs supported in SVC_Handler_IPC(). > > I propose to modify the SVC_Handler_IPC() function's 'default' handler to invoke a locally defined weak function such as below: > > default: > return (custom_ipc_svc_handlers(svc_num, ctx, lr)); > > __attribute__((weak)) > int32_t custom_ipc_svc_handlers(tfm_svc_number_t svc_num, uint32_t *ctx, uint32_t lr) { > LOG_MSG("Unknown SVC number requested!"); > return PSA_ERROR_GENERIC_ERROR; > } > > This will allow a 'strong'ly defined custom_ipc_svc_handlers() function to be invoked if provided. > > Is this OK? > > Another approach is for me to hijack the root SVC handler in the secure vector table, but this seems too heavy handed to me. > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M