TF-M February 2019

tf-m@lists.trustedfirmware.org

15 participants
49 discussions

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

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

7 years, 2 months

[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

7 years, 2 months

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M February 2019