- TF-M - lists.trustedfirmware.org

Re: [TF-M] How to run PSA API compliance tests with TF-M Crypto

by Antonio De Angelis

Hi all, All the patches needed to pass all the PSA API Compliance tests from the ew_beta0 branch have been merged into TF-M master branch, so there is no need for step [2] below, just checkout the TF-M master branch. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 31 January 2019 21:42 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [Tf-m] How to run PSA API compliance tests with TF-M Crypto Hi all, after a restructuring of the patches in the pull request, the patch that needs to be checked out at step [2] in the instructions in the mail below is amended to: 2. Checkout https://review.trustedfirmware.org/c/trusted-firmware-m/+/588/ Thanks, Antonio ________________________________ From: Antonio De Angelis Sent: 30 January 2019 17:21 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: How to run PSA API compliance tests with TF-M Crypto Hi all, It’s possible to run a subset of the PSA API Compliance tests with the TF-M Crypto service by following the instructions below (it assumes that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/tree/ew_beta0 (ew_beta0 branch of the PSA API Compliance tests repo) 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/561/ 3. Copy the interface/include/psa_crypto.h to interface/include/psa/crypto.h as this is the header name expected by the PSA API Compliance tests 4. Build the Crypto tests for the PSA API compliance as described in the psa-arch-tests/api-tests for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include) * The list of tests being run is specified in the file psa-arch-tests/api-tests/dev_apis/crypto/testsuite.db * For example, this command will build the tests for AN521 “./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite crypto --include ../../trusted-firmware-m/interface/include --archive_tests” 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for Crypto by adding the following cmake switch during the configuration step: “-DPSA_API_TEST_CRYPTO=ON” * For example, this command will build the TF-M + NS app with PSA API Crypto tests for AN521 “cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_CRYPTO=ON ../” This will make our NS test app run a subset of the PSA API compliance tests for Crypto. We are currently working on fixing the remaining failures. Thanks, Antonio -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] generated header files

by Mate Toth-Pal

Hi Alan, Currently the generation of these files is a manual step that should be done prior to build. The script that does the generation is the tools/tfm_parse_manifest_list.py python script. The script has to be run with no command line parameters from the TF-M source root dir. The location of two files, tools\tfm_generated_file_list.yaml and tools\tfm_manifest_list.yaml are hardcoded into the script, and they specify the files the script works on. tfm_manifest_list.yaml contains the list of partition manifest files. These yaml files provide the information that template files have to be filled with. tfm_generated_file_list.yaml contains the list of files to be generated. The script assumes, that for each <generated_file_path>/<generated_file_name> there is a file <generated_file_path>/<generated_file_name>.template file, which is used as a template for generation. Please note, that the current version of this script on master contains a custom parser and substituting code, however we have a plan to replace it to the Jinja2 template parser engine. Please see the proposal here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 07 February 2019 22:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] generated header files I'm using the feature-ipc branch and I notice a lot of these warnings in TF-M header files: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ When are these files generated? I assume they're derived from associated manifest files. When I use cmake to create a "ConfigCoreIPC.cmake" build area, I don't see any header files being generated in the process. Any changes I've made to header files with these warnings are still present. Is there a TF-M cmake configuration that regenerates these files? If so, how do I invoke it so I can more properly reconfigure a custom SP? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

generated header files

by DeMars, Alan

I'm using the feature-ipc branch and I notice a lot of these warnings in TF-M header files: /*********** WARNING: This is an auto-generated file. Do not edit! ***********/ When are these files generated? I assume they're derived from associated manifest files. When I use cmake to create a "ConfigCoreIPC.cmake" build area, I don't see any header files being generated in the process. Any changes I've made to header files with these warnings are still present. Is there a TF-M cmake configuration that regenerates these files? If so, how do I invoke it so I can more properly reconfigure a custom SP? Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by Miklos Balint

Hi Alan, https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans. For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fu… Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. Are you concerned that this overhead is a major limitation? If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point. /M -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 03 February 2019 15:18 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: Non-secure Client Management Ken, Thank you for your prompt response. Please see my replies below. Alan > Hi Alan, > The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. Is their a feature rollout schedule that I can follow? > The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of >> DeMars, Alan via TF-M >> Sent: Sunday, February 3, 2019 9:17 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [Tf-m] Non-secure Client Management >> >> Regarding the Non-secure Client Management proposal: >> >> >> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem >> ent/ >> >> I notice that the veneers for the proposed APIs are in s_veneers.o. >> Does this mean that the proposal has been adopted and implemented? Is >> it functional in the current feature-ipc branch? >> >> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >> Is it expected that each context switch in the NS world will be >> signaled by calls to each of these APIs indicating the "entering" >> context and "leaving" context respectively? If so, then why not >> collapse these two APIs into one called >> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >> TZ_MemoryId_t's as arguments? >> >> Or is TZ_StoreContext_S() only to be called when a NS context will >> never call into the SPM again? If that is the case, why isn't >> TZ_FreeModuleContext_S() sufficient? >> >> Regarding the "Concurrent secure service requests" discussion, what >> does "a non-secure client is blocked on an asynchronous secure service completion"? >> Would this be achieved by a special return status from psa_call() >> indicating that the current service request is in process and will >> complete later on? The psa_call() calling thread would then block on >> a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? >> >> Alan

6 years, 2 months

1
0
0 0

Re: [TF-M] IRQ handling by Secure Partitions proposal

by Miklos Balint

Hi Alan, 0, One thing to point out is that my proposal only covers the "Library" or function-call-based model that was the only one implemented on TF-M master branch at the time of writing. PSA Firmware Framework v1.0 with its IPC mechanism has its own design of how interrupts are supposed to be handled by secure threads - my proposal intends to complement that with the same functionality for the other operating model. This clarification addresses point 5 as well, I believe. 1, SPM "Acknowledges the interrupt": this is not the best wording. Actually this is very bad wording. What I meant to say is that SPM's own interrupt handler is started - which is a hardware action, not one by SPM - and SPM ISR in turn masks the interrupt line in NVIC. As you rightly point out, the peripheral itself is of no concern to SPM, that's the business for partition code, either in its own Partition ISR, or a service function. 2. This means that secure PSP is saved for the pre-empted context, set to the stack of the partition that's the owner of the interrupt line, and any additional housekeeping associated with a context switch (PSPLIM setup, isolation re-configuration, privilege setting - all according to the properties of the partition that is to be activated). Lastly, a mock context is created on the partition stack so that the Partition ISR can be activated with an exception return from the SPM ISR. 3a. The Partition ISR is activated by SPM ISR by doing an exception return to the start address of e.g. UART1_ISR() function. In order for this TF-M first needs to create the mock context mentioned in my point 2. The discussion of the stack frame in the text is meant to clarify that there are two possibilities that need to be considered: if the partition is idle, i.e. there are no ongoing service requests in its context, its stack pointer is either at a default value or - potentially - there's no stack associated with the partition. In that case a stack frame needs to be initialized and the mock context set up there. If the partition is handling a request, its original stack pointer needs to be used as the start address for the mock context used for exception return. 3b. After execution of the Partition ISR, execution is returned to the SPM ISR. At this point, SPM can decide to either re-activate the original context that had been pre-empted by the interrupt, or, can take a scheduling decision to activate a different context, e.g. the partition that had called psa_wait(). 4. The current implementation does not allow for the pre-emption of a secure context by non-secure scheduling events, but that is a limitation that could likely be lifted depending on some basic policies that have to be set up by the system integrator. In such a case the NS thread would be blocked waiting on the completion of the secure service, but a pre-emptive NS OS could schedule a different thread if the time slice of the caller thread runs out. Other options are subject to investigation at this point. ... Please let me know if any of the points I've addressed provide clarity instead of making the design more obscure, in which case I would update the design proposal with the extra information. :) And of course let me know if you have further questions. Regards Miklos -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 02 February 2019 04:29 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] IRQ handling by Secure Partitions proposal Regarding the "SPM behavior" discussion in the "Secure Partition Interrupt Handling" proposal: 1) What is meant by the SPM "Acknowledges the interrupt"? I understand "masks the hardware interrupt line" but I don't see how the SPM can know how to acknowledge a particular peripheral's interrupt. I think acknowledging the interrupt should be done by the "Partition ISR" dedicated to the interrupt, or within the corresponding SP's main loop upon return from psa_wait(). 2) What does "Sets up execution environment for the secure partition" mean, precisely? 3) Can you expand on the "Execute Partition ISR" paragraph a little? I assume you mean that, for instance, the registered UART1_isr() function is called. The discussion of the ISR stack frame I don't really follow. And from the description, I'm not sure when the SP is scheduled to run again to deal with the ISR it was waiting for. 4) A secure partition that depends on an interrupt begs the question of what happens to the NS thread that has called into the SP requesting some service that depends on a subsequent asynchronous event (ISR) to complete the request. The psa_call() function as currently implemented doesn't "block" in the traditional OS sense (ie the thread's context and state are not saved in a manner that allows another task thread to run while the psa_call() is stalled in the SPM waiting for an ISR. 5) The details of SP thread pre-emption and re-entrancy need to be described. Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Re: [TF-M] [Tf-m] Issues porting to new toolchain

by Mate Toth-Pal

Hi Thomas, 1) If you can provide implementations in standard C, then yes, it can be a benefit 2) Yes, I think that would make the code review easier. 3) You are right, adding ifdefs to C files should not be the way to go. As GNUARM doesn't provide symbols like this, we could easily solve this problem by creating the symbols in the ld file to be the same as the ones generated by the ARMCLANG toolchain. One option is to do the same for the EWARM toolchain as for GNUARM. I had a quick look at the EWARM Development Guide, and it seems that the linker configuration file supports this feature (exporting symbols, and using expressions with start/end addresses of elf sections). Another way to go would be to move the REGION_DECLARE, REGION_NAME, and related macros to a compiler specific header file, like tfm_compiler.h. Then this file could be placed in the platforms' toolchain specific directories. This solution would have the benefit, that the multiple definitions of the macros would be reduced to a single one. However to me this seems to be a greater effort: - The build system have to be modified to add the platform specific folder as include folder for compilation - The macros should be restructured a bit, as there would be a need for LOAD_REGION_DECLARE(...), EXECUTION_REGION_DECLARE_RW(...), EXECUTION_REGION_DECLARE_RO(...) and more (at least based on my quick look at the code) - All the source files have to be updated to use the new macros and include the specific header 4) The way to solve this could be to create a new function in the Compiler<tooolchain>Common.cmake files, called something like get_pre_include_parameter, that generates the proper option (--preinclude of -include) and call that function in BuildMbedtls.cmake Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 04 February 2019 15:41 To: DeMars, Alan via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [Tf-m] Issues porting to new toolchain Greetings, I am working on adding IAR Embedded Workbench for ARM (EWARM) as a supported toolchain for TF-M and I would like to discuss some of the issues I've run into before I start issuing PR:s. 1) The current TF-M source uses non-standard gcc extensions which EWARM does not support. I assume it should not be an issue converting this code into standard C, that would only help porting to other toolchains as well. 2) Should I create separate PR:s for these changes and the toolchain changes? 3) In some places (tfm_core.c, ...) there are hardwired references to symbols like Image$$TFM_UNPRIV_SCRATCH$$ZI$$Base, Image$$TFM_UNPRIV_SCRATCH$$ZI$$Limit. Our toolchain would use symbols like TFM_UNPRIV_SCRATCH$$Base and TFM_UNPRIV_SCRATCH$$Limit instead. What to do about this? Adding #ifdefs in the .c files will be messy and I'd like some cleaner solution. 4) Some common cmake files contains hardwired option names like "-include" (BuildMbedtls.cmake) Our toolchain uses "--preinclude" instead and I think this ought to be handled in the compiler specific cmake files instead. -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Issues porting to new toolchain

by Thomas Törnblom

Greetings, I am working on adding IAR Embedded Workbench for ARM (EWARM) as a supported toolchain for TF-M and I would like to discuss some of the issues I've run into before I start issuing PR:s. 1) The current TF-M source uses non-standard gcc extensions which EWARM does not support. I assume it should not be an issue converting this code into standard C, that would only help porting to other toolchains as well. 2) Should I create separate PR:s for these changes and the toolchain changes? 3) In some places (tfm_core.c, ...) there are hardwired references to symbols like Image$$TFM_UNPRIV_SCRATCH$$ZI$$Base, Image$$TFM_UNPRIV_SCRATCH$$ZI$$Limit. Our toolchain would use symbols like TFM_UNPRIV_SCRATCH$$Base and TFM_UNPRIV_SCRATCH$$Limit instead. What to do about this? Adding #ifdefs in the .c files will be messy and I'd like some cleaner solution. 4) Some common cmake files contains hardwired option names like "-include" (BuildMbedtls.cmake) Our toolchain uses "--preinclude" instead and I think this ought to be handled in the compiler specific cmake files instead. -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

6 years, 2 months

1
0
0 0

Re: [Tf-m] [TF-M] How to run PSA API compliance tests with TF-M SST service

by Shebu Varghese Kuriakose

Adding TF-M mailing list and Prasanth Hi Murat, Looking at the list of subscribed members, you are not yet registered to TF-M mailing list. Please try subscribing using the link in https://www.trustedfirmware.org/contact/. You will receive a mail which you need to acknowledge before you get subscribed. Check your spam as well for the mail asking for acknowledgement. On the topic below, the extended tests are for testing against the optional/extended SST Protected Storage APIs. These APIs are optional and so not required to pass for PSA Functional API certification. The SST patch set below doesn’t support those optional SST PS APIs. From what I last heard, Marc and team has verified all the other mandatory SST PS Tests on MuscaA using the patches below. TF-M team or Prasanth might be able to advise on what might be going wrong. Regards, Shebu -----Original Message----- From: murat(a)za-ya.co <murat(a)za-ya.co> Sent: Sunday, February 3, 2019 10:29 AM To: Marc Moreno Berengue <Marc.MorenoBerengue(a)arm.com> Cc: nd <nd(a)arm.com>; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> Subject: RE: [Tf-m] [TF-M] How to run PSA API compliance tests with TF-M SST service Dear Marc, Thank you for introductions. We are now running PSA SST tests on Musca board, and as we see there are only three test suites (p011, p012, p013), the other test suites are empty. And when we run the PSA SST tests, SST tests skip even existing three test cases. This is because the first test case asks for supported API and expects " PSA_PS_SUPPORT_SET_EXTENDED " static const test_data p011_data[] = { { VAL_PS_GET_SUPPORT, PSA_PS_SUPPORT_SET_EXTENDED /* Check if optional PS API supported */ }, And TF-m (https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/589/ ) does not the support extended PSA API yet as we see from enum tfm_sst_err_t tfm_sst_get_support(uint32_t *support_flags) { /* * This function returns a bitmask with flags set for all of the optional * features supported by the SST service implementation. * * SST service does not support the optional extended PSA PS API yet. <<<<<<<<<<<<<<<<<<<<< NO SUPPORT */ *support_flags = 0; <<<<<<<<<<<<<<<<<<<<< NO SUPPORT return TFM_SST_ERR_SUCCESS; } And PSA Test Suite skips the all remaining test case if there is no EXTENDED API Support. 0.000 - 00>Test Case not needed as Optional PS APIs are not supported. 0.000 - 00>TEST RESULT: SKIPPED (Skip Code=0x2b) 0.000 - 00>****************************************** 0.000 - 00>************ Protected Storage Suite Report ********** 0.000 - 00>TOTAL TESTS : 3 0.000 - 00>TOTAL PASSED : 0 0.000 - 00>TOTAL SIM ERROR : 0 0.000 - 00>TOTAL FAILED : 0 0.000 - 00>TOTAL SKIPPED : 3 0.000 - 00>****************************************** 0.000 - 00>Entering standby.. Is it the expected behaviour for Musca Port or are we missing something? (We are registered but we don’t receive any e-mail from the TF-m mail list, I don’t know how to see your response 😊 ) Thank you. Best Regards. Murat -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Marc Moreno Berengue via TF-M Sent: 01 February 2019 18:25 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [Tf-m] [TF-M] How to run PSA API compliance tests with TF-M SST service Hi all, The Secure Storage (SST) service has been updated to align it with the PSA Protected Storage APIs version 1.0. There are a set of patches which implements this change. Please, find more information about those changes in the following ticket: https://developer.trustedfirmware.org/T218 It's possible to run the PSA API Compliance tests (https://github.com/ARM-software/psa-arch-tests/tree/master/api-tests/dev_ap…) with the TF-M SST service by following the instructions below. (The instructions assume that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/ 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/589/ 3. Copy the `interface/include/psa_protected_storage.h` to `interface/include/psa/protected_storage.h` as this is the header name expected by the PSA API Compliance tests 4. Build the SST tests for the PSA API compliance as described in the `psa-arch-tests/api-tests` for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include). Set crypto and internal trusted storage as not implemented in `psa-arch-tests/api-tests/platform/targets/<TARGET_NAME>/Makefile`. Set PSA_CRYPTO_IMPLEMENTED:=0 and PSA_INTERNAL_TRUSTED_STORAGE_IMPLEMENTED:=0 * The list of tests being run is specified in the file `psa-arch-tests/api-tests/dev_apis/protected_storage/testsuite.db` * For example, this command will build the tests for AN521 "./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite protected_storage --include ../../trusted-firmware-m/interface/include --archive_tests" 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for SST service by adding the following cmake switch during the configuration step: "-DPSA_API_TEST_SECURE_STORAGE=ON" * For example, this command will build the TF-M + NS app with PSA API Protected Storage tests for AN521 "cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_SECURE_STORAGE=ON ../" This will make our NS test app run a subset of the PSA API compliance tests for SST service. Thanks, Marc Moreno -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

2
1
0 0

Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management

by DeMars, Alan

Ken, Thank you for your prompt response. Please see my replies below. Alan > Hi Alan, > The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. Is their a feature rollout schedule that I can follow? > The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing. > The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. > > -Ken > >> -----Original Message----- >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, >> Alan via TF-M >> Sent: Sunday, February 3, 2019 9:17 AM >> To: tf-m(a)lists.trustedfirmware.org >> Subject: [Tf-m] Non-secure Client Management >> >> Regarding the Non-secure Client Management proposal: >> >> >> https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/ >> >> I notice that the veneers for the proposed APIs are in s_veneers.o. Does this >> mean that the proposal has been adopted and implemented? Is it functional in >> the current feature-ipc branch? >> >> I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: >> Is it expected that each context switch in the NS world will be signaled by calls to >> each of these APIs indicating the "entering" context and "leaving" context >> respectively? If so, then why not collapse these two APIs into one called >> TZ_SwitchContext__S() and pass both the "entering" and "leaving" >> TZ_MemoryId_t's as arguments? >> >> Or is TZ_StoreContext_S() only to be called when a NS context will never call into >> the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() >> sufficient? >> >> Regarding the "Concurrent secure service requests" discussion, what does "a >> non-secure client is blocked on an asynchronous secure service completion"? >> Would this be achieved by a special return status from psa_call() indicating that >> the current service request is in process and will complete later on? The psa_call() >> calling thread would then block on a semaphore that would be released by a >> dedicated NS IRQ interrupt? Is any of this functionality in place yet? >> >> 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

6 years, 2 months

1
0
0 0

Re: [Tf-m] Non-secure Client Management

by Ken Liu (Arm Technology China)

Hi Alan, The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later. The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching. The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Sunday, February 3, 2019 9:17 AM > To: tf-m(a)lists.trustedfirmware.org > Subject: [Tf-m] Non-secure Client Management > > Regarding the Non-secure Client Management proposal: > > > https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/ > > I notice that the veneers for the proposed APIs are in s_veneers.o. Does this > mean that the proposal has been adopted and implemented? Is it functional in > the current feature-ipc branch? > > I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: > Is it expected that each context switch in the NS world will be signaled by calls to > each of these APIs indicating the "entering" context and "leaving" context > respectively? If so, then why not collapse these two APIs into one called > TZ_SwitchContext__S() and pass both the "entering" and "leaving" > TZ_MemoryId_t's as arguments? > > Or is TZ_StoreContext_S() only to be called when a NS context will never call into > the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() > sufficient? > > Regarding the "Concurrent secure service requests" discussion, what does "a > non-secure client is blocked on an asynchronous secure service completion"? > Would this be achieved by a special return status from psa_call() indicating that > the current service request is in process and will complete later on? The psa_call() > calling thread would then block on a semaphore that would be released by a > dedicated NS IRQ interrupt? Is any of this functionality in place yet? > > Alan > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Non-secure Client Management

by DeMars, Alan

Regarding the Non-secure Client Management proposal: https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/ I notice that the veneers for the proposed APIs are in s_veneers.o. Does this mean that the proposal has been adopted and implemented? Is it functional in the current feature-ipc branch? I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: Is it expected that each context switch in the NS world will be signaled by calls to each of these APIs indicating the "entering" context and "leaving" context respectively? If so, then why not collapse these two APIs into one called TZ_SwitchContext__S() and pass both the "entering" and "leaving" TZ_MemoryId_t's as arguments? Or is TZ_StoreContext_S() only to be called when a NS context will never call into the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() sufficient? Regarding the "Concurrent secure service requests" discussion, what does "a non-secure client is blocked on an asynchronous secure service completion"? Would this be achieved by a special return status from psa_call() indicating that the current service request is in process and will complete later on? The psa_call() calling thread would then block on a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet? Alan

6 years, 2 months

1
0
0 0

IRQ handling by Secure Partitions proposal

by DeMars, Alan

Regarding the "SPM behavior" discussion in the "Secure Partition Interrupt Handling" proposal: 1) What is meant by the SPM "Acknowledges the interrupt"? I understand "masks the hardware interrupt line" but I don't see how the SPM can know how to acknowledge a particular peripheral's interrupt. I think acknowledging the interrupt should be done by the "Partition ISR" dedicated to the interrupt, or within the corresponding SP's main loop upon return from psa_wait(). 2) What does "Sets up execution environment for the secure partition" mean, precisely? 3) Can you expand on the "Execute Partition ISR" paragraph a little? I assume you mean that, for instance, the registered UART1_isr() function is called. The discussion of the ISR stack frame I don't really follow. And from the description, I'm not sure when the SP is scheduled to run again to deal with the ISR it was waiting for. 4) A secure partition that depends on an interrupt begs the question of what happens to the NS thread that has called into the SP requesting some service that depends on a subsequent asynchronous event (ISR) to complete the request. The psa_call() function as currently implemented doesn't "block" in the traditional OS sense (ie the thread's context and state are not saved in a manner that allows another task thread to run while the psa_call() is stalled in the SPM waiting for an ISR. 5) The details of SP thread pre-emption and re-entrancy need to be described. Alan

6 years, 2 months

1
0
0 0

Re: [Tf-m] Required GCC tools for reference implementation

by Tamas Ban

There is an ongoing activity to merge the feature-ipc branch to master. Tamas -----Original Message----- From: DeMars, Alan <ademars(a)ti.com> Sent: 01 February 2019 23:16 To: Tamas Ban <Tamas.Ban(a)arm.com> Cc: nd <nd(a)arm.com> Subject: RE: Required GCC tools for reference implementation Excellent! Will this change be merged into the feature-ipc branch soon? Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Tamas Ban via TF-M Sent: Friday, February 01, 2019 2:01 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [Tf-m] Required GCC tools for reference implementation Hi Alan, Since this change the GNUARM v7.3 also supported: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/421/ Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 February 2019 20:59 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] Required GCC tools for reference implementation Is there a compelling reason that the reference implementation of the PSA requires the use of the gcc-arm-none-eabi-6-2017-q1-update gnu tools? The linker in these tools generates a non-standard s_veneers.o file that cannot be consumed by some CLANG linkers. It should be a relocatable object file with absolute symbols, but instead it's static executable file. If I use a newer GCC linker (ie: gcc-arm-none-eabi-7-2017-q4-major) for the final link of the secure image, the generated s_veneers.o file is of the correct type. Alan DeMars -- 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

6 years, 2 months

1
0
0 0

Re: [Tf-m] Required GCC tools for reference implementation

by Tamas Ban

Hi Alan, Since this change the GNUARM v7.3 also supported: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/421/ Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 01 February 2019 20:59 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] Required GCC tools for reference implementation Is there a compelling reason that the reference implementation of the PSA requires the use of the gcc-arm-none-eabi-6-2017-q1-update gnu tools? The linker in these tools generates a non-standard s_veneers.o file that cannot be consumed by some CLANG linkers. It should be a relocatable object file with absolute symbols, but instead it's static executable file. If I use a newer GCC linker (ie: gcc-arm-none-eabi-7-2017-q4-major) for the final link of the secure image, the generated s_veneers.o file is of the correct type. Alan DeMars -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 2 months

1
0
0 0

Required GCC tools for reference implementation

by DeMars, Alan

Is there a compelling reason that the reference implementation of the PSA requires the use of the gcc-arm-none-eabi-6-2017-q1-update gnu tools? The linker in these tools generates a non-standard s_veneers.o file that cannot be consumed by some CLANG linkers. It should be a relocatable object file with absolute symbols, but instead it's static executable file. If I use a newer GCC linker (ie: gcc-arm-none-eabi-7-2017-q4-major) for the final link of the secure image, the generated s_veneers.o file is of the correct type. Alan DeMars

6 years, 2 months

1
0
0 0

[TF-M] How to run PSA API compliance tests with TF-M SST service

by Marc Moreno Berengue

Hi all, The Secure Storage (SST) service has been updated to align it with the PSA Protected Storage APIs version 1.0. There are a set of patches which implements this change. Please, find more information about those changes in the following ticket: https://developer.trustedfirmware.org/T218 It's possible to run the PSA API Compliance tests (https://github.com/ARM-software/psa-arch-tests/tree/master/api-tests/dev_ap…) with the TF-M SST service by following the instructions below. (The instructions assume that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/ 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/589/ 3. Copy the `interface/include/psa_protected_storage.h` to `interface/include/psa/protected_storage.h` as this is the header name expected by the PSA API Compliance tests 4. Build the SST tests for the PSA API compliance as described in the `psa-arch-tests/api-tests` for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include). Set crypto and internal trusted storage as not implemented in `psa-arch-tests/api-tests/platform/targets/<TARGET_NAME>/Makefile`. Set PSA_CRYPTO_IMPLEMENTED:=0 and PSA_INTERNAL_TRUSTED_STORAGE_IMPLEMENTED:=0 * The list of tests being run is specified in the file `psa-arch-tests/api-tests/dev_apis/protected_storage/testsuite.db` * For example, this command will build the tests for AN521 "./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite protected_storage --include ../../trusted-firmware-m/interface/include --archive_tests" 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for SST service by adding the following cmake switch during the configuration step: "-DPSA_API_TEST_SECURE_STORAGE=ON" * For example, this command will build the TF-M + NS app with PSA API Protected Storage tests for AN521 "cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_SECURE_STORAGE=ON ../" This will make our NS test app run a subset of the PSA API compliance tests for SST service. Thanks, Marc Moreno

6 years, 2 months

1
0
0 0

How to run PSA API compliance tests with TF-M Crypto

by Antonio De Angelis

Hi all, It's possible to run a subset of the PSA API Compliance tests with the TF-M Crypto service by following the instructions below (it assumes that psa-arch-tests and trusted-firmware-m directories are at the same level in the filesystem): 1. Checkout https://github.com/ARM-software/psa-arch-tests/tree/ew_beta0 (ew_beta0 branch of the PSA API Compliance tests repo) 2. Checkout https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/561/ 3. Copy the interface/include/psa_crypto.h to interface/include/psa/crypto.h as this is the header name expected by the PSA API Compliance tests 4. Build the Crypto tests for the PSA API compliance as described in the psa-arch-tests/api-tests for one of the supported targets, providing the include path of the TF-M interface (i.e. trusted-firmware-m/interface/include) * The list of tests being run is specified in the file psa-arch-tests/api-tests/dev_apis/crypto/testsuite.db * For example, this command will build the tests for AN521 "./tools/scripts/setup.sh --target tgt_dev_apis_tfm_an521 --toolchain ARMCLANG --cpu_arch armv8m_ml --verbose 2 --suite crypto --include ../../trusted-firmware-m/interface/include --archive_tests" 5. Build TF-M by using the ConfigPsaApiTest.cmake, enabling the PSA API Compliance tests for Crypto by adding the following cmake switch during the configuration step: "-DPSA_API_TEST_CRYPTO=ON" * For example, this command will build the TF-M + NS app with PSA API Crypto tests for AN521 "cmake -G"Unix Makefiles" -DPROJ_CONFIG=`readlink -f ../ConfigPsaApiTest.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=ARMCLANG -DPSA_API_TEST_CRYPTO=ON ../" This will make our NS test app run a subset of the PSA API compliance tests for Crypto. We are currently working on fixing the remaining failures. Thanks, Antonio

6 years, 2 months

1
1
0 0

IPC patches merged into branch 'feature-ipc'

by Ken Liu (Arm Technology China)

Hi Subscribers, Group of IPC patches has been merged into branch 'feature-ipc'. The features are: * PSA Firmware Framework API (based on scheduler and message queue) and example partitions. * Isolation level 1 * Verified on AN521 You can find the design link here: https://developer.trustedfirmware.org/w/tf_m/design/ipc_design/ Some issues are identified and need to be solved. We will publish the list of improvements soon. Any feedback please mail to tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> You can also create questions and issues at https://developer.trustedfirmware.org Thanks. -Ken

6 years, 2 months

1
0
0 0

Re: [Tf-m] Replace custom code generating scripts with Jinja2

by Ken Liu (Arm Technology China)

Hi Mate, Thanks for the proposal. It looks nice. I have read the "Improvements over the current solution" part and I think the "More advanced functionality" is the point I am interested in. There are some necessary jobs to be done in the code generating scripts for IPC; hope using this tool could help on that. One thing we are investigating is: * We need to put PSA RoT and APP RoT into different groups in linker script; current tool just put all partitions together and ignores partition type. Can you help to check if the new tool could make this change easier? Thanks. -Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Mate Toth-Pal via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, January 21, 2019 8:37:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: [Tf-m] Replace custom code generating scripts with Jinja2 Hi All, Based on the design proposal published here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… I am planning to replace the code generation tool currently used in the TF-M with the Jinja2 template engine. I already prepared the change that implements this. It is available for review and testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ Please note, that this introduces a new tool dependency: jinja2 v2.10 python library have to be installed to generate code from the partition manifests. Earlier than 2.10 versions won't work, as one of the templates relies on the namespace feature introduced in this version. Based on this change I also would like to make the secure sct files automatically generated (just like the secure ld files). The gerrit review for this change is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Should you have any questions, suggestions, objections, please do not hesitate to contact! Thanks, Mate -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
1
0 0

Replace custom code generating scripts with Jinja2

by Mate Toth-Pal

Hi All, Based on the design proposal published here: https://developer.trustedfirmware.org/w/tf_m/design/code_generation_with_ji… I am planning to replace the code generation tool currently used in the TF-M with the Jinja2 template engine. I already prepared the change that implements this. It is available for review and testing in this gerrit review: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/507/ Please note, that this introduces a new tool dependency: jinja2 v2.10 python library have to be installed to generate code from the partition manifests. Earlier than 2.10 versions won't work, as one of the templates relies on the namespace feature introduced in this version. Based on this change I also would like to make the secure sct files automatically generated (just like the secure ld files). The gerrit review for this change is here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/509/ Should you have any questions, suggestions, objections, please do not hesitate to contact! Thanks, Mate

6 years, 3 months

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Darshpreet Sabharwal

Hi Thomas >> Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Yes, we are aiming to release an updated TF-M pack this month with updated TF-M source code. Regards Darshpreet -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 09 January 2019 15:45 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] ARM.TFM CMSIS pack questions Thanks Antonio, I now think I know what the dependency on CMSIS 5.2.0 is. In tfm_id_mngr_dummy.c, which seems to have been removed recently, there are a couple of calls into private functions of the RTX5 library which are declared "static" in the later versions of CMSIS, and this causes link errors when using later versions of CMSIS. Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Thanks, Thomas Den 2019-01-08 kl. 15:20, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > After this patch has been merged in November: > http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328 > e94bcae2d762169bd30f3d7ebc0c2880b5b > > We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of > Thomas Törnblom via TF-M > Sent: 07 January 2019 11:48 > To: tf-m(a)lists.trustedfirmware.org > Subject: [Tf-m] ARM.TFM CMSIS pack questions > > Greetings! > > I am working on adding support for IAR Embedded Workbench for ARM > (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: > --- > 2. The Non-Secure API supports CMSIS 5.2.0 version only. > --- > > What specifically requires version 5.2.0 that would not work with a later version? > > The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? > > 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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Thomas Törnblom

Thanks Antonio, I now think I know what the dependency on CMSIS 5.2.0 is. In tfm_id_mngr_dummy.c, which seems to have been removed recently, there are a couple of calls into private functions of the RTX5 library which are declared "static" in the later versions of CMSIS, and this causes link errors when using later versions of CMSIS. Is there any work in progress on updating the TFM CMSIS Pack to use the updated TFM sources? Thanks, Thomas Den 2019-01-08 kl. 15:20, skrev Antonio De Angelis via TF-M: > Hi Thomas, > > After this patch has been merged in November: > http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328e94bc… > > We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. > > Thanks, > Antonio > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M > Sent: 07 January 2019 11:48 > To: tf-m(a)lists.trustedfirmware.org > Subject: [Tf-m] ARM.TFM CMSIS pack questions > > Greetings! > > I am working on adding support for IAR Embedded Workbench for ARM > (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: > --- > 2. The Non-Secure API supports CMSIS 5.2.0 version only. > --- > > What specifically requires version 5.2.0 that would not work with a later version? > > The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? > > 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>

6 years, 3 months

1
0
0 0

Re: [Tf-m] ARM.TFM CMSIS pack questions

by Antonio De Angelis

Hi Thomas, After this patch has been merged in November: http://git.trustedfirmware.org/trusted-firmware-m.git/commit/?id=2b328e94bc… We don't have any reliance on CMSIS 5.2.0 internals anymore and we use only the public CMSIS interface in the Non-Secure API. As a result, I don't see any reason now that stops us from using newer versions of CMSIS. I have actually tried to build TF-M and run regression using CMSIS 5.3.0 and it works as expected. Can you try to see if you're able to build with CMSIS 5.5.0 as well? In case you see issues, I should be able to have a look to understand them better and come with a solution. Thanks, Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 07 January 2019 11:48 To: tf-m(a)lists.trustedfirmware.org Subject: [Tf-m] ARM.TFM CMSIS pack questions Greetings! I am working on adding support for IAR Embedded Workbench for ARM (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: --- 2. The Non-Secure API supports CMSIS 5.2.0 version only. --- What specifically requires version 5.2.0 that would not work with a later version? The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? 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> -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 3 months

1
0
0 0

ARM.TFM CMSIS pack questions

by Thomas Törnblom

Greetings! I am working on adding support for IAR Embedded Workbench for ARM (EWARM) to the ARM.TFM.1.1.0 CMSIS Pack and in the ReadMe.txt file in the pack there is a list of limitations, of which I would like an explanation for the following: --- 2. The Non-Secure API supports CMSIS 5.2.0 version only. --- What specifically requires version 5.2.0 that would not work with a later version? The problem is that I've run across some issues that needs fixing in the ARM.CMSIS pack as well, so I've fixed these in the upcoming 5.5.0 version and would like to know what the issues are using this version with TFM? 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>

6 years, 3 months

1
0
0 0

TF-m Musca_A Tickets

by murat＠za-ya.co

Hi all, We are trying to run the TF-m on Musca-A board, but we have found some blocker issues * T-165: Musca A wrong offset for Secure/NonSecure ROM Alias <https://developer.trustedfirmware.org/T165> * T-166: Is it missing to initialise the MPC for Non-Secure QSPI address range? <https://developer.trustedfirmware.org/T166> Once we apply the fixes mentioned in the tickets, TF-m works well on Musca Board so, could you please review tickets, we might create PRs for them. Best Regards. Murat Cakmak

6 years, 4 months

1
0
0 0

IPC design and implementation ready for review

by Ken Liu (Arm Technology China)

Hi folks, The IPC design and implementation for PSA API are now pushed for review. This design showcases: - PSA Firmware Framework compatible IPC implementation You can find the design document here: https://developer.trustedfirmware.org/w/tf_m/design/ipc_design/ And issue tracker with gerrit items commented: https://developer.trustedfirmware.org/T113 Discussion and review comments are welcome. We will continue work on IPC topics for missing pieces. Thanks. -Ken

6 years, 4 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Antonio De Angelis

Hi Miklos, thanks for the feedback. I think that having the prototype as shown below, would be very helpful from services point of view. Best regards, Antonio ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Miklos Balint via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 15 December 2018 15:39:12 To: tf-m(a)lists.trustedfirmware.org Cc: nd Subject: Re: [Tf-m] Uniform secure service signature proposal To clarify: my suggestion is to update the signature to be identical to a RoT service call: psa_status_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); If that is accepted, I would update the proposal accordingly. Thanks /Miklos (wmnt) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: 15 December 2018 16:33 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] Uniform secure service signature proposal Hi Antonio, Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear. The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t. While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal. Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal. Thanks /Miklos (wmnt) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 12 December 2018 16:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [Tf-m] Uniform secure service signature proposal Hi Miklos/Mate, Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature. int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M. *Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function? In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend). Thanks in advance for any feedback on this observation. Thanks, Antonio -- 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

6 years, 4 months

1
0
0 0

IRQ handling by Secure Partitions proposal

by Miklos Balint

Hi all, Apologies. Opening a new thread for the new design proposal: Please see the following link for a design proposal on IRQ handling by Secure Partitions in TF-M: https://developer.trustedfirmware.org/w/tf_m/design/secure_partition_interr… Any comments are welcome - preferably on this thread :) Regards /Miklos (wmnt)

6 years, 4 months

1
0
0 0

Uniform secure service signature proposal

by Miklos Balint

Hi all, Mate and myself have created a design proposal for uniform secure service signatures to provide more compatibility between PSA Firmware Framework and TF-M, to provide framework-level parameter sanitization for services and automatic non-secure callable veneer generation for the functions. https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… Regards /Miklos (wmnt) IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 4 months

1
2
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Miklos Balint

To clarify: my suggestion is to update the signature to be identical to a RoT service call: psa_status_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); If that is accepted, I would update the proposal accordingly. Thanks /Miklos (wmnt) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Miklos Balint via TF-M Sent: 15 December 2018 16:33 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [Tf-m] Uniform secure service signature proposal Hi Antonio, Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear. The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t. While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal. Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal. Thanks /Miklos (wmnt) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 12 December 2018 16:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [Tf-m] Uniform secure service signature proposal Hi Miklos/Mate, Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature. int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M. *Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function? In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend). Thanks in advance for any feedback on this observation. Thanks, Antonio -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 4 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Miklos Balint

Hi Antonio, Thanks for the comment. You are right, the return value of secure services should be explicitly typed to make its usage clear. The thought process behind the current proposal was to provide a similar look-and-feel to the psa_call( ) function in the PSA Firmware Framework, i.e. to return something that is in line with psa_status_t since, as you mentioned, PSA services are already expected to provide a status code of type psa_status_t. While the proposal failed to mention this, the restrictions present in TF-M currently for services with proprietary signatures would not apply to services with uniform signatures. So while at present services are expected to respect the reserved range of return values defined by TF-M, that would not be the case for services with uniform signatures. The analogy would be that the value provided to psa_reply() as a status code in the PSA Firmware Framework (described in version 1.0-beta-0 chapter 4.3.3 of that document) should be the return value from a secure service function with a "uniform signature" in my proposal. Mate is working on some prototype code for this change in the return value to demonstrate. Let me know if this would work for you or if anyone has additional comments related to the topic/proposal. Thanks /Miklos (wmnt) -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: 12 December 2018 16:16 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [Tf-m] Uniform secure service signature proposal Hi Miklos/Mate, Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature. int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M. *Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function? In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend). Thanks in advance for any feedback on this observation. Thanks, Antonio -- 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.

6 years, 4 months

1
0
0 0

Re: [Tf-m] Uniform secure service signature proposal

by Antonio De Angelis

Hi Miklos/Mate, Thanks for the detailed proposal. I have a comment/question regarding the return type to be used in the unified signature. int32_t secure_function_name(struct psa_invec *in_vec, size_t in_len, struct psa_outvec *out_vec, size_t out_len); The type returned is a int32_t. As a service developer, I have to be aware that although the type returned by the service is a int32_t, there is a set of reserved return codes which are reserved by the TF-M framework and can't be used freely by the service itself (as described in interface/include/tfm_api.h through the enum tfm_status_e type, only allowed values are below the TFM_PARTITION_SPECIFIC_ERROR_MIN). As a consequence, the services right now need to define their own return type and make sure the values don't clash with the values reserved by TF-M. *Question is*: what is your opinion on explicitly marking the return type here with a dedicated type (instead of a plain int32_t) which enforces the fact that not all possible return values are usable by the service/secure function? In addition to this, in case the feedback is positive, I think that the new type we choose/define should be aligned as much as possible with the patterns of the return types used by the service API's and this would help secure service developers. Currently in fact, as TF-M is reserving return values between 0x01 and 0x1F, an intermediate translation step is required, for everything different than TFM_SUCCESS, to align the values returned by services to the values that the API's return (take again in example the Crypto service which returns psa_status_t, when the return values are propagated back to the API interface, the TFM_PARTITION_SPECIFIC_ERROR_MIN needs to be removed every time). If we define our new type as to be still based on int32_t, but with TF-M reserved values in a very high range (e.g. between -0x1F and -0x1) this would save the translation step and won't clash with the return values that are defined by the services (or, at least, this seems to be the current trend). Thanks in advance for any feedback on this observation. Thanks, Antonio

6 years, 4 months

1
0
0 0

Attestation implementation proposal

by Laurence Lundblade

Hi folks, I’m a contractor doing an implementation of attestation based on EAT <https://tools.ietf.org/html/draft-mandyam-eat-01> for TF-M. Tamas asked that I post the proposed architecture here for discussion. It is in this ticket: https://developer.trustedfirmware.org/T152 LL

6 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M