Hi,
The following task lists some of the changes that we had to make to enable
TF-M to be built using ExternalProject_Add from Zephyr, as well as enabling
the
use of ninja for TF-M builds (which is often significantly faster than
using classic
makefiles): https://developer.trustedfirmware.org/T760
The ninja changes have been tested with:
$ cmake -GNinja -DPROJ_CONFIG=`readlink -f ../configs/ConfigDefault.cmake`
-DTARGET_PLATFORM=LPC55S69 -DBL2=False -DCOMPILER=GNUARM ..
$ ninja
The changes to imgtool.py resolve some platform issues when signing
binaries, and add a convenience requirements.txt file that can be run in CI
to ensure that all of the Python dependencies are met for this tool.
Any concerns or feedback on these are welcome, but I would be interested to
hear
any opinions on ninja which is often considerably faster out of the box
when compiling
(at least on Linux and native OS X, which is what I use for my builds).
Best regards,
Kevin
Hi Ken,
I agree that FPCCR_S.TS (in addition to other setting for FP) should be set if FPU needs to be used in secure world. The FPCCR.LSPEN allows saving the context lazily which was what I was referring to previously. Eventhough the hardware is performing the stacking, the policy chosen (lazy stacking/stack always) affects interrupt latency which should be considered for the design for FPU usage in TF-M.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 01 June 2020 15:55
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] DSP instructions and FPU use
Hi Soby & Andrej,
The FP context is managed by hardware automatically in M-profile architecture.
While booting we clear FPCA since we are not using FP under handler mode, we don't want FP get involved during initialization and need extra clean up job.
But if a thread uses FP the FPCA is set to 1 automatically, and if exceptions are happening the FP context stacked automatically by hardware - the secure scheduler just keep the EXC_RETURN which contains FP context and finally recover it back.
Which means if you enabled hardware FP unintentional it can work, the only place a problem may occur should be the non-secure preempting secure execution case.
I think the only thing we are missing now is we did not set FPCCR_S.TS = 1 since we did not realize that user would enable FP in secure world. This would cause the FP register may contain secure information while Non-secure preempting secure execution. Need to go through the settings and double-check.
So at least before we finish the estimation I think FPCCR_S.TS should be set to ensure the security.
Andrej, have you set this bit while you are using hardware FP? Or just let it go (use default TF-M setting)?
Thanks.
/Ken
From: Soby Mathew <Soby.Mathew(a)arm.com<mailto:Soby.Mathew@arm.com>>
Sent: Monday, June 1, 2020 5:25 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: DSP instructions and FPU use
Hi,
For enabling floating point the ARMv8-M architecture allows the flowing possibilities :
* Stacking the basic Floating-point context.
* Stacking the basic Floating-point context and the additional Floating-point context.
* Activation of Lazy Floating-point state preservation.
The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts.
Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: 01 June 2020 09:05
To: 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] DSP instructions and FPU use
Hi Andrej,
You mean the hardware floatpoint can be used in the Secure Partition?
That's a good information, can you share us the compiler flags about float-point you are using? Thanks.
/Ken
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Monday, June 1, 2020 2:46 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: DSP instructions and FPU use
FYI: >> Can you do some experiments on enabling hardware float point and see if it is working
In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, June 1, 2020 8:41 AM
To: 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] DSP instructions and FPU use
Hi Cindy,
The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default.
Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation.
During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch.
For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load).
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M
Sent: Friday, May 29, 2020 6:39 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] DSP instructions and FPU use
Hello,
I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image).
About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file).
Is there a reason for that? Maybe some performance reasons?
About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions?
Thank you in advance for the answer,
Best regards,
Cindy
Hi Brian,
Did you empty the build directory before you build? And this is the recommended commit id for each of the repositories:
Mbed-crypto: 1146b4e06011b69a6437e6b728f2af043a06ec19 Tag mbedcrypto-3.0.1
Mbedtls: 3187e7ca986fe199313343b0c810e41b543ef78a Tag mbedtls-2.7.9
CMSIS_5: 80cc44bba16cb4c8f495b7aa9709d41ac50e9529 Tag 5.2.0
Could you share us the commit id of each repo and the toolchain version (arm-none-eabi-gcc -v) you are using?
Thanks,
Shawn
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Quach, Brian via TF-M
Sent: Tuesday, June 2, 2020 7:25 AM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] build error
Hi All,
I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution?
mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install
[ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1
[ 0%] Built target tfm_s_pp_tfm_common_s_1
[ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o
/tmp/ccpVCp1C.s: Assembler messages:
/tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3'
secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed
make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1
CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed
make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi All,
I'm using the latest TF-M, embedTLS, and CMSIS 5 code (repo HEAD). I renamed embedtls to embed-crypto. I ran "cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=AN521 -DCOMPILER=GNUARM" which seemed to execute fine, but I'm getting an error on the next step. Does anyone know the solution?
mnt/c/Gits/trusted-firmware-m/cmake_build$ cmake --build ./ -- install
[ 0%] Built target tfm_s_pp_image_macros_to_preprocess_s_1
[ 0%] Built target tfm_s_pp_tfm_common_s_1
[ 0%] Building C object secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o
/tmp/ccpVCp1C.s: Assembler messages:
/tmp/ccpVCp1C.s:47: Error: syntax error -- `msr psplim,r3'
secure_fw/CMakeFiles/tfm_s_obj_lib.dir/build.make:86: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o' failed
make[2]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/spm/spm_func.o] Error 1
CMakeFiles/Makefile2:189: recipe for target 'secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all' failed
make[1]: *** [secure_fw/CMakeFiles/tfm_s_obj_lib.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
Regards,
Brian Quach
SimpleLink MCU
Texas Instruments Inc.
12500 TI Blvd, MS F-4000
Dallas, TX 75243
214-479-4076
Hi,
For enabling floating point the ARMv8-M architecture allows the flowing possibilities :
* Stacking the basic Floating-point context.
* Stacking the basic Floating-point context and the additional Floating-point context.
* Activation of Lazy Floating-point state preservation.
The easiest way would be to enable FP context stacking for every context switch but it would impact every context switch irrespective of whether FP unit is used in that context or not . I guess this is the approach taken by Andrej ? . The Lazy Floating point state preservation would be better for performance but it would have additional complexity in managing the contexts.
Just blue sky thinking here: There could be a middle ground wherein some partitions are allowed to use FP while others are not because they don't really need to. The ones allowed to use FP will need to cater for the additional stack requirement to save FP context. The actual save of the context can be done either on context switch to the partition or lazily. This approach could give the benefit of both performance and memory savings but it requires some analysis and design to be done in TF-M.
Best Regards
Soby Mathew
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: 01 June 2020 09:05
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] DSP instructions and FPU use
Hi Andrej,
You mean the hardware floatpoint can be used in the Secure Partition?
That's a good information, can you share us the compiler flags about float-point you are using? Thanks.
/Ken
From: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>
Sent: Monday, June 1, 2020 2:46 PM
To: Ken Liu <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>>
Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: RE: DSP instructions and FPU use
FYI: >> Can you do some experiments on enabling hardware float point and see if it is working
In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M
Sent: Monday, June 1, 2020 8:41 AM
To: 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] DSP instructions and FPU use
Hi Cindy,
The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default.
Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation.
During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch.
For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load).
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M
Sent: Friday, May 29, 2020 6:39 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] DSP instructions and FPU use
Hello,
I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image).
About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file).
Is there a reason for that? Maybe some performance reasons?
About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions?
Thank you in advance for the answer,
Best regards,
Cindy
FYI: >> Can you do some experiments on enabling hardware float point and see if it is working
In our SDK, the LPC55S HW Float point is enabled for all TFM projects (Kel, GCC/MCUx), and it works.
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M
Sent: Monday, June 1, 2020 8:41 AM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] DSP instructions and FPU use
Hi Cindy,
The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default.
Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation.
During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch.
For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load).
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Cindy Chaumont via TF-M
Sent: Friday, May 29, 2020 6:39 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] DSP instructions and FPU use
Hello,
I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image).
About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file).
Is there a reason for that? Maybe some performance reasons?
About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions?
Thank you in advance for the answer,
Best regards,
Cindy
Hi Cindy,
The reason is we need to estimate the potential security risks after enabling hardware floating-point, so it is set as software FPU as default.
Can you do some experiments on enabling hardware float point and see if it is working, and then let's see the patch? That would be helpful for our estimation.
During bootup, we cleared the CONTROL.FPCA, and if you access hardware float point in a partition thread should work because it would re-invoke the FPCA bit and make everything work as usual. But as I mentioned, we need to estimate it and give a proper solution and then enable your patch.
For DSP, a similar reason is there, we need to take an estimation. But in theory, you can enable the things you have on the hardware, just be caution that the shared resources between S/NS can be the risk (and the resource sharing caused - co-work problem, the context save/load).
Thanks.
/Ken
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Cindy Chaumont via TF-M
Sent: Friday, May 29, 2020 6:39 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] DSP instructions and FPU use
Hello,
I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image).
About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file).
Is there a reason for that? Maybe some performance reasons?
About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions?
Thank you in advance for the answer,
Best regards,
Cindy
Hi,
As the first commit of 'source_structure' document is merged, here is the first patch to follow the document:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4315
The patch looks big, even it just adjusts the content inside 'secure_fw'. To make the related sources can pass the building, some files out of the 'secure_fw' need to be changed. The goal of merging is ASAP so that we won't block upcoming features.
Please provide the feedback about potential USAGE problem you may meet. As the patch is big, it won't be applicable to make THIS patch perfect to meet all the requirements defined in the document, a series of upcoming patches would come as amending.
Also if there are suggestions about the structure document, please write to the mailing list and put discussion in this task:
https://developer.trustedfirmware.org/T751
The rendered structure document:
https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/252/artifact/bui…
BR
/Ken
Hello,
I am using the GNUARM compiler and LPCXpresso55S69-EVK dev board and I would like to use DSP instructions and FPU (in secure image).
About FPU, it seems there is no way to use the hardware floating-point support instead of the software support (see "-msoft-float" flag in CommonConfig.cmake file).
Is there a reason for that? Maybe some performance reasons?
About DSP, in CompilerGNUARMxy.cmake files, architecture definition is preferred to CPU type and, in my case, "-march=armv8-m.main" flags is chosen (without +dsp option). The solution I found is to only define ARM_CPU_TYPE (and not ARM_CPU_ARCHITECTURE) to use "-mcpu=cortex-m33" flag instead of "-march=armv8-m.main". So I can use DSP instructions. However, I am not sure if this is the best solution. Maybe an option could be added to allow or not the use of DSP instructions?
Thank you in advance for the answer,
Best regards,
Cindy
Hi all,
TF-M Profile Small patches are merged in TF-M master branch. Thanks a lot for all your review, comments and support.
I'd appreciate it if you could feedback and share ideas while enabling Profile Small in your actual use cases. If there is any issue, please feel free to let us know.
Thank you.
The next step will bring in symmetric key algorithm based Initial Attestation and then Profile Small can have a full set of features.
Best regards,
Hu Ziji