June 2021 - TF-M - lists.trustedfirmware.org

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi, This secure test service, as I mentioned in the previous email, is for test purpose only. I’d like to recommend to implement a dedicated secure service to co-work with TF-M Initial Attestation service, to fulfil the specific use cases. This test service can be an example. The factory NS app and the dedicated secure service may work in a special device lifecycle. It may require additional mechanism to protect it from accesses in improper lifecycle. It may not be reasonable to mix an API with special purpose with TF-M Initial Attestation service following PSA Attestation API. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: Friday, June 18, 2021 3:05 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>) <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

2 years, 10 months

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Tamas Ban

Hi, The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228 I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database. Kevin: Would this solution still satisfy your use case in mind? My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime. * Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation. BR, Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend(a)linaro.org) <kevin.townsend(a)linaro.org>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi Kevin, In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec. On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers. Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service. Best regards, Hu Ziji From: Kevin Townsend <kevin.townsend(a)linaro.org<mailto:kevin.townsend@linaro.org>> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> wrote: Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

2 years, 10 months

1
0
0 0

Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

by Kevin Townsend

Hi, On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi all, > > > > Please note that API tfm_initial_attest_get_public_key() has been removed > from TF-M Initial Attestation service. > > > > tfm_initial_attest_get_public_key() was defined by TF-M to retrieve > Initial Attestation Key (IAK) public key in runtime. > > It is not defined by PSA Attestation API spec. It was designed for test > purpose only but was always enabled in Initial Attestation service. > > > > TF-M regression tests called tfm_initial_attest_get_public_key() in > runtime to retrieve IAK public key to verify the Initial Attestation Token > (IAK) generated by Initial Attestation service. > > However, such a test implementation doesn’t fully align with common > attestation protocols, in which the public key is usually distributed to > the verifier when the device is deployed or registered. > > This API can be misleading and it concerned developers that it may be > abused in actual production. > > Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused? Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users. Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt. There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed. If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise! Best regards, Kevin

2 years, 10 months

2
1
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

Thanks for the quick response! That build now works for me. Chris From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, June 17, 2021 7:55 AM To: Mark Horvath <Mark.Horvath(a)arm.com>; Brand Chris (CSCA CSS ICW SW PSW 1) <Chris.Brand(a)infineon.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com> Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

2 years, 10 months

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by David Hu

The fix is merged. Thanks to Chris for reporting this issue. Also thanks to Mark for such a quick fix. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: Thursday, June 17, 2021 2:59 PM To: tf-m(a)lists.trustedfirmware.org; Chris.Brand(a)infineon.com Subject: Re: [TF-M] Building for Musca B1 with proxy service Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

2 years, 10 months

1
0
0 0

TF-M API tfm_initial_attest_get_public_key() has been removed

by David Hu

Hi all, Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service. tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service. TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn't fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production. Therefore this API is removed now. A hard-coded dummy public key file is exported instead, to provide the pre-defined public key data to TF-M regression tests. This dummy public key is hard-coded here<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…>. The removal of this API doesn't impact TF-M Initial Attestation service functionalities. TF-M Initial Attestation service still works as PSA attestation API spec requests. The changes to TF-M regression tests are either transparent to platform port or tests. However, there are two exceptions: - Currently, some develop boards with OTP enabled are provisioned with random IAK pair. The public key is unknown to the attestation verifier. Therefore a dedicated attestation test partition<https://git.trustedfirmware.org/TF-M/tf-m-tests.git/tree/test/test_services…> is added to workaround this issue. It adds back API tfm_initial_attest_get_public_key() to retrieve IAK public key in runtime. Boards with similar limitations can select flag ATTEST_TEST_GET_PUBLIC_KEY to enable this workaround during TF-M regression tests. This test partition is only available for TF-M regression tests. It is recommended to enable this workaround *only when it is necessary*. - When developers integrate TF-M with 3rd party test tool, developers can pick the dummy public key file and include it into IAK verification tests as public key input. Sorry for any inconvenience or trouble if this removal impacts your ongoing task. Please let me know if you have further questions about the removal of API tfm_initial_attest_get_public_key(). Best regards, Hu Ziji

2 years, 10 months

1
0
0 0

Re: [TF-M] Building for Musca B1 with proxy service

by Mark Horvath

Hi Chris, The build failure is a regression caused by moving the arm platforms under arm directory. Here is the patch to fix it: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10333 No need to pass artifacts from SE build to SSE-200 build, and the warning about the redefinition is not nice, but that does not cause any issue. Best regards, Mark ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Chris.Brand--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, June 16, 2021 11:34 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Building for Musca B1 with proxy service Hi, I’m trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I’m getting errors for the SSE-200 build and my various attempts to get around them have all failed. I’m (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. […] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition […] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it’s the include paths that are messed up somehow…? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

2 years, 10 months

1
0
0 0

Documentation URLs

by Anton Komlev

Hi, You might noticed that recently documentation became available under the static links (no randomized part in URL anymore). Now it possible to bookmark or share the TF-M docs using a human friendly short URLs like: https://tf-m-user-guide.trustedfirmware.org/docs/introduction/readme.html Please try and enjoy, Anton

2 years, 10 months

1
0
0 0

Building for Musca B1 with proxy service

by Chris.Brand＠infineon.com

Hi, I'm trying to build for the Musca B1 with the proxy service. I understand that I have to two separate builds, one for the secure_enclave and one for the SSE-200. The secure enclave build works fine, but I'm getting errors for the SSE-200 build and my various attempts to get around them have all failed. I'm (also) wondering if there are artifacts form the secure_enclave build that need to feed into the SSE-200 build somehow, and if so how that works. Here's my command line and resulting errors: cmake -S . -B build_musca_sse200_GNUARM_Relwithdebinfo '-GUnix Makefiles' -DTFM_PLATFORM=arm/musca_b1/sse_200 -DTFM_TOOLCHAIN_FILE=toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Relwithdebinfo -DTFM_PSA_API=ON -DFORWARD_PROT_MSG=ON In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/bl0/bl0_main.c:17:0: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/gcc/startup_cmsdk_musca_bl2.S:20:10: fatal error: tfm_plat_config.h: No such file or directory #include "tfm_plat_config.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. In file included from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/platform_description.h:23:0, from /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/system_core_init.c:23: /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Include/cmsis.h:63:10: fatal error: core_cm33.h: No such file or directory #include <core_cm33.h> /*!< Arm Cortex-M33 processor and core peripherals */ ^~~~~~~~~~~~~ compilation terminated. /lhome/cbrand/work/trees_2/psoc6_atfm/trusted-firmware-m/platform/ext/target/arm/musca_b1/sse_200/Device/Source/device_definition.c:29:10: fatal error: tfm_plat_defs.h: No such file or directory #include "tfm_plat_defs.h" ^~~~~~~~~~~~~~~~~ compilation terminated. [...] <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition <command-line>:0:0: warning: "FORWARD_PROT_MSG" redefined <command-line>:0:0: note: this is the location of the previous definition [...] platform/target/bl0/CMakeFiles/bl0.dir/build.make:86: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/bl0_main.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... platform/target/bl0/CMakeFiles/bl0.dir/build.make:138: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/system_core_init.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:125: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/device_definition.o] Error 1 platform/target/bl0/CMakeFiles/bl0.dir/build.make:81: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o' failed gmake[2]: *** [platform/target/bl0/CMakeFiles/bl0.dir/__/Device/Source/gcc/startup_cmsdk_musca_bl2.o] Error 1 CMakeFiles/Makefile2:2539: recipe for target 'platform/target/bl0/CMakeFiles/bl0.dir/all' failed gmake[1]: *** [platform/target/bl0/CMakeFiles/bl0.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs.... This is from a clean checkout of 54d47fbd5269 (current HEAD). I see that my tree does contain platform/ext/cmsis/core_cm33.h, platform/include/tfm_plat_config.h and platform/include/tfm_plat_defs.h so I guess it's the include paths that are messed up somehow...? Thanks, Chris Brand Cypress Semiconductor (Canada), Inc. Sr Prin Software Engr CSCA CSS ICW SW PSW 1 Office: +1 778 234 0515 Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>

2 years, 10 months

1
0
0 0

Technical Forum call - June 24

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 24 7:00-8:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

2 years, 10 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M June 2021