- TF-M - lists.trustedfirmware.org

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Sorry. Switch into plain text and correct the bad format. Something was wrong with the Outlook. Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations a. If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. b. If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 2. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

Please review multi-core TF-M topology improvement patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patches to improve topology implementation on `feature-twincpu` branch? https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 ~ https://review.trustedfirmware.org/c/trusted-firmware-m/+/1549 and https://review.trustedfirmware.org/c/trusted-firmware-m/+/1603/ As you know, we are bringing up TF-M on multi-core topology platform. Currently, preprocessor directives TFM_MULTI_CORE_TOPOLOGY are used to comment/uncomment the functionalities here and there to fit different scenarios. It can work but makes code difficult to be understood or maintained, in both single Armv8-M and multi-core topologies. The above patches try to eliminate multi-core directives from common sequence and functions shared by single Armv8-M and multi-core topologies. It is expected to not only improve the code readability, but also protect one topology from being affected by changes to another. Although those changes are for twincpu feature branch, I'd like to ask for review and comment since they also impact the single Armv8-M scenario. Merging feature-twincpu branch back to master would be more smooth if we can figure out and fix issues now on `feature-twincpu`. I'd like to summarize the common basic ideas of the topology implementation. 1. If single Armv8-M and multi-core topology both call the same API but require different implementations * If that API can be classified to a specific functionality/module, separate the implementations into topology exclusive files. Take https://review.trustedfirmware.org/c/trusted-firmware-m/+/1542 as an example. Add multi-core specific NS Client ID implementations in tfm_multi_core.c. Thus multi-core topology doesn't rely on the single Armv8-M implementations in tfm_nspm.c. Then all the multi-core directives can be removed from tfm_nspm.c and tfm_nspm.c can be clearly excluded from multi-core topology build. * If that API don't belong to a specific functionality/module, extract it out and organize the implementations in topology abstraction file. For example, in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1545, tfm_core_topology_set_pendsv_priority() is defined to wrap the PendSV settings in diverse topologies. The implementations are selected according to current topology in tfm_core_topology.h. It help maintain a more clear and uniform sequence by removing multi-core directives from tfm_core.c. 1. In common sequence, if an API is called in single Armv8-M but not used in multi-core topology, add an empty function for this API in multi-core topology in the header file and vice versa. For example, secure core in multi-core topology doesn't need to configure_ns_code(). As show in https://review.trustedfirmware.org/c/trusted-firmware-m/+/1543, instead of placing several multi-core directives in tfm_core.c, move configure_ns_code() implementation to tfm_nspm.c and define an empty function in header file tfm_nspm.h in multi-core topology for configure_ns_code(). Any comment or suggestion is welcome. Please kindly let me know if the above changes may cause troubles in single Armv8-M scenario. Thank you. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

Re: [TF-M] Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The hotfix has been merged. /Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu > (Arm Technology China) via TF-M > Sent: Monday, July 22, 2019 4:37 PM > To: tf-m(a)lists.trustedfirmware.org > Cc: nd <nd(a)arm.com> > Subject: [TF-M] Hotfix for auto-merge caused build error > > Hi, > The gerrit merge with auto rebase on this patch caused the function type change > and a build error is generated: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 > > A hotfix is on the way for fixing this: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 > > Sorry for the troublesome. > > /Ken > > > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

Hotfix for auto-merge caused build error

by Ken Liu (Arm Technology China)

Hi, The gerrit merge with auto rebase on this patch caused the function type change and a build error is generated: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1560 A hotfix is on the way for fixing this: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1602 Sorry for the troublesome. /Ken

5 years, 11 months

1
0
0 0

Please help review memory access check design for multi-core topology

by David Hu (Arm Technology China)

Hi all, Could you please help review the design of TF-M memory access check in multi-core topology on https://review.trustedfirmware.org/c/trusted-firmware-m/+/1601 ? Since CMSE support is likely to be unavailable on multi-core platforms, that design proposes a general memory access check process for multi-core topology and corresponding HAL APIs to retrieve platform specific memory attribute configurations. Any comment would be gratefully received. If this design may not work in certain use cases, it would be very helpful if you can let me know the details. Thank you. Best regards, Hu Ziji

5 years, 11 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by DeMars, Alan

Mate, Thank you for your response. I discovered not long after I posted my inquiry that recent merges to master should resolve the problem I'm having. I'm in the process of pulling in those commits locally. Thanks again, Alan -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Mate Toth-Pal via TF-M Sent: Friday, July 19, 2019 1:22 PM To: TF-M(a)lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] including platform specific interrupt definitions Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

Re: [TF-M] including platform specific interrupt definitions

by Mate Toth-Pal

Hi Alan, I'm not sure on what version of TF-M is your base. This part of TF-M changed recently. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1354/ This change introduced the generated manifest header files. For each partition a header file is generated, which contains the signals for the partition. Both IRQ signals, and normal signals in case of IPC mode. Up to the following change all the signals (except for IRQ) had to be defined manually in a header file tfm_spm_signal_defs.h. This replaces the manually created IPC model signal definitions to the generated signals: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1356/ This does the same to the IRQ signals (up until this change, IRQ signals had to be defined in tfm_irq_signal_defs.h): https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1589/ This, and the related changes remove the manually created signal files. https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1382/ So depending on your base you either need to manually define the signals, or should have it automatically once the generator script is run. As a general advice I would suggest to look at the IRQ signal 'SPM_CORE_IRQ_TEST_1_SIGNAL_TIMER_0_IRQ' which is the IRQ signal for one of the test services, and see where it appears and compare it to yours. Also if you could publish some of your code in the gerrit, we might be able help to find out what is the problem. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 19 July 2019 18:35 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] including platform specific interrupt definitions I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

including platform specific interrupt definitions

by DeMars, Alan

I'm trying to add s secure interrupt to my secure partition manifest but am getting a compile error because there are no definitions of my secure interrupt IRQ name and SIGNAL name. What is the mechanism for including a platform-specific header that defines platform specific interrupts when compiling "secure_fw/core/ipc/tfm_svcalls.c"? Alan

5 years, 11 months

1
0
0 0

Re: [TF-M] Missing veneer function implementations

by Kevin Townsend

Hi Mate, I was able to get this working by changing the build config to a non-IPC setup (ConfigDefault.cmake), in which case the tfm veneers functions are available and I can call the PSA API shims directly: SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_tfm_crypto_generate_random_veneer 100efc88 g F *ABS* 00000008 tfm_tfm_crypto_get_generator_capacity_veneer ... Thanks for the clarification. Calling `psa_generate_random` from the NSPE works are expected now. Best regards, Kevin On Wed, 17 Jul 2019 at 14:16, Mate Toth-Pal via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Kevin, > > Based on what you write your build is probably OK. To access the > psa_generate_random service, you need to call the function 'psa_status_t > psa_generate_random(uint8_t *output, size_t output_size)', declared in > interface/include/psa/crypto.h. > > in case the TFM/PSA APIs are in use (your case), the transition to the > secure code is done through the tfm_psa_* veneers. A service (for example > psa_generate_random) is connected with a call to 'psa_connect(...)', which > is provided with the ID of the selected service, and then 'psa_call(...)' > is called with the handle received from 'psa_connect(...)' (as it is > described in the PSA FF Specification). However this exchange is > implemented inside the TF-M's crypto API implementation in > interface\src\tfm_crypto_api.c, so you only need to call the API function. > > The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M > when the Library model is used. In this case the secure services can be > accessed with a single function call, and the tfm_psa_* veneers are not > available. However please note, that even in this case you can use TF-M's > crypto API, which will call the service the correct way. (Look for the > conditionally compiled blocks depending on the TFM_PSA_API macro in the API > implementation.) > > I hope this answers your questions. > > Regards, > Mate > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin > Townsend via TF-M > Sent: 17 July 2019 13:12 > To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> > Subject: [TF-M] Missing veneer function implementations > > Greetings, > > I'm trying to get the TFM/PSA APIs working in Zephyr, based on the > upstream TF-M repository. > > The libraries are being built with the following settings, followed by > make and make install: > > cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f > ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ > > *ConfigRegressionIPC is used simply to include the test service for > debugging purposes for now. > > The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making > calls to the SPE via the PSA APIs, which should call the appropriate > veneers via the source files in the `install/export/tfm` folder, as well as > `veneers/s_veneers.o` > > This works fine calling the test service via `tfm_psa_call_veneer`, but > whenever I try to make use of any of the .c shims in the PSA API (for > example `psa_generate_random`), I get the following error(s): > > tfm_crypto_api.c:1571: undefined reference to > `tfm_tfm_crypto_generate_random_veneer' > > I assumed the veneers are in the `s_veneers.o` file generated as part of > the TF-M build, and this file is linked into during the Zephyr build > process, but when I look at the contents of the .o file (which was > suspiciously small at 740b) I only see the following: > > $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o > > /tfm/build/install/export/tfm/veneers/s_veneers.o: file format > elf32-littlearm > > SYMBOL TABLE: > 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer > 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S > 100efc90 g F *ABS* 00000008 TZ_LoadContext_S > > 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer > 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer > 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S > 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer > 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S > 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests > 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S > 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer > 100efcd8 g F *ABS* 00000008 tfm_register_client_id > > Clearly I'm missing something in the build process so that all of the > other veneers are present, but it's not obvious to me at this point what. > At present I can only make calls to `tfm_psa_call` to the test service, but > that isn't going to help with the goal of publishing a sample application > that meets the requirements for PSA Level 1 certification. > > Any suggestions on what knob to turn to include the missing veneers would > be very welcome. > > Best regards, > Kevin Townsend > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

5 years, 11 months

2
1
0 0

Re: [TF-M] Missing veneer function implementations

by Mate Toth-Pal

Hi Kevin, Based on what you write your build is probably OK. To access the psa_generate_random service, you need to call the function 'psa_status_t psa_generate_random(uint8_t *output, size_t output_size)', declared in interface/include/psa/crypto.h. in case the TFM/PSA APIs are in use (your case), the transition to the secure code is done through the tfm_psa_* veneers. A service (for example psa_generate_random) is connected with a call to 'psa_connect(...)', which is provided with the ID of the selected service, and then 'psa_call(...)' is called with the handle received from 'psa_connect(...)' (as it is described in the PSA FF Specification). However this exchange is implemented inside the TF-M's crypto API implementation in interface\src\tfm_crypto_api.c, so you only need to call the API function. The veneer 'tfm_tfm_crypto_generate_random_veneer' is compiled into TF-M when the Library model is used. In this case the secure services can be accessed with a single function call, and the tfm_psa_* veneers are not available. However please note, that even in this case you can use TF-M's crypto API, which will call the service the correct way. (Look for the conditionally compiled blocks depending on the TFM_PSA_API macro in the API implementation.) I hope this answers your questions. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 17 July 2019 13:12 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Missing veneer function implementations Greetings, I'm trying to get the TFM/PSA APIs working in Zephyr, based on the upstream TF-M repository. The libraries are being built with the following settings, followed by make and make install: cmake -G\"Unix Makefiles\" -DPROJ_CONFIG=`readlink -f ../ConfigRegressionIPC.cmake` -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM ../ *ConfigRegressionIPC is used simply to include the test service for debugging purposes for now. The SPE is handled by TF-M, and the NSPE uses Zephyr, with zephyr making calls to the SPE via the PSA APIs, which should call the appropriate veneers via the source files in the `install/export/tfm` folder, as well as `veneers/s_veneers.o` This works fine calling the test service via `tfm_psa_call_veneer`, but whenever I try to make use of any of the .c shims in the PSA API (for example `psa_generate_random`), I get the following error(s): tfm_crypto_api.c:1571: undefined reference to `tfm_tfm_crypto_generate_random_veneer' I assumed the veneers are in the `s_veneers.o` file generated as part of the TF-M build, and this file is linked into during the Zephyr build process, but when I look at the contents of the .o file (which was suspiciously small at 740b) I only see the following: $ arm-none-eabi-objdump -t tfm/build/install/export/tfm/veneers/s_veneers.o /tfm/build/install/export/tfm/veneers/s_veneers.o: file format elf32-littlearm SYMBOL TABLE: 100efc80 g F *ABS* 00000008 tfm_psa_framework_version_veneer 100efc88 g F *ABS* 00000008 TZ_InitContextSystem_S 100efc90 g F *ABS* 00000008 TZ_LoadContext_S 100efc98 g F *ABS* 00000008 tfm_psa_version_veneer 100efca0 g F *ABS* 00000008 tfm_psa_close_veneer 100efca8 g F *ABS* 00000008 TZ_FreeModuleContext_S 100efcb0 g F *ABS* 00000008 tfm_psa_connect_veneer 100efcb8 g F *ABS* 00000008 TZ_AllocModuleContext_S 100efcc0 g F *ABS* 00000008 tfm_secure_client_service_veneer_run_tests 100efcc8 g F *ABS* 00000008 TZ_StoreContext_S 100efcd0 g F *ABS* 00000008 tfm_psa_call_veneer 100efcd8 g F *ABS* 00000008 tfm_register_client_id Clearly I'm missing something in the build process so that all of the other veneers are present, but it's not obvious to me at this point what. At present I can only make calls to `tfm_psa_call` to the test service, but that isn't going to help with the goal of publishing a sample application that meets the requirements for PSA Level 1 certification. Any suggestions on what knob to turn to include the missing veneers would be very welcome. Best regards, Kevin Townsend -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M