- TF-M - lists.trustedfirmware.org

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, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 4 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

7 years, 5 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M