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
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
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
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
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
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
>
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
Hi All,
I've pushed a set of patches for review which aims to add the following features to MCUBoot:
* Integration with HW key(s).
* Sign & authenticate S and NS image independently with different keys.
Design proposal for this change:
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/
Related changes are listed here:
https://developer.trustedfirmware.org/T438
Please feel free to review any of the patches.:)
Thanks,
Tamas
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