- TF-M - lists.trustedfirmware.org

by Shawn Shan

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

6 years, 1 month

1
0
0 0

build error

by Quach, Brian

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

6 years, 1 month

1
0
0 0

Re: [TF-M] DSP instructions and FPU use

by Soby Mathew

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

6 years, 1 month

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Andrej Butok

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

6 years, 1 month

2
1
0 0

Re: [TF-M] DSP instructions and FPU use

by Ken Liu

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

6 years, 1 month

1
0
0 0

[IMPORTANT] [SOURCE STRUCTURE] The first structure adjust patch is pushed

by Ken Liu

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

6 years, 1 month

1
0
0 0

DSP instructions and FPU use

by Cindy Chaumont

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

6 years, 1 month

1
0
0 0

TF-M Profile Small patches merged

by David Hu

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

6 years, 1 month

1
0
0 0

Correction - MMIO region is not sharable between partitions

by Ken Liu

Hi, In the tech forum I mentioned a potential way of sharing MMIO regions - this is not correct. Double checked the PSA FF and it is defined explicitly in the spec page 43: "A Secure Partition always has exclusive access to an MMIO region. Secure Partitions are not allowed to share MMIO regions with other Secure Partitions and MMIO regions are not allowed to overlap." Sorry for the confusion. BR /Ken

6 years, 1 month

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Jonatan Antoni

Hi Gyorgy, Ken, Let me add one statement to Gyorgy's > It became a de-facto standard and most compilers support it. Compilers not yet supported can be easily added, if required. Cheers, Jonatan From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: 27 May 2020 10:45 To: Ken Liu <Ken.Liu(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, One of the most well working part of CMSIS is the compiler abstraction layer: * It does wat is needed. * Most functionality can not be coded in a different way (i.e. intrinsics). * It became a de-facto standard and most compilers support it. What are the benefits driving re-implementation? /George 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: 27 May 2020 02:39 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] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Jamie, At the current stage: * The CMSIS headers dependency has been moved into HAL, the SPM native code would not rely on specific system provided definitions. * These usages are quite TF-M specific and small so there is less significance to upstream back, we can revisit if need to do this after extended the header content - but this extending is out of original design expectation. BR /Ken From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Tuesday, May 26, 2020 10:52 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: [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie 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: 25 May 2020 05:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

6 years, 1 month

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Gyorgy Szing

Hi Ken, One of the most well working part of CMSIS is the compiler abstraction layer: * It does wat is needed. * Most functionality can not be coded in a different way (i.e. intrinsics). * It became a de-facto standard and most compilers support it. What are the benefits driving re-implementation? /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 May 2020 02:39 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Jamie, At the current stage: * The CMSIS headers dependency has been moved into HAL, the SPM native code would not rely on specific system provided definitions. * These usages are quite TF-M specific and small so there is less significance to upstream back, we can revisit if need to do this after extended the header content - but this extending is out of original design expectation. BR /Ken From: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Sent: Tuesday, May 26, 2020 10:52 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: [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie 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: 25 May 2020 05:02 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

6 years, 1 month

2
1
0 0

Re: [TF-M] Pre-provisioned keys

by Tamas Ban

Hi Brian, The pre-provisioned keys are highly platform dependent. TF-M just provide an API to access them, but currently we have no standard/general solution to storing them. There was question a few weeks ago related to same topic. I just copied Shebu's past answer here: "Provisioning was added as a future roadmap item in anticipation of a PSA Provisioning Specification. The Specification (Factory or application specific) hasn't happened so far. There is no active work ongoing in TF-M around provisioning. TF-M using provisioned keys in CC-312 on MuscaB1 platform is available as an example. See details here<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> under CC312 heading. In TrustedFirmware TSC, provisioning has been a discussion topic sometime back. Search for provisioning in the minutes below. https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md is an RFC that Kevin prepared during those discussions for TF-M devices to use certificate chain. " I hope this helps! Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 27 May 2020 03:41 To: tf-m(a)lists.trustedfirmware.org; Quach, Brian <brian(a)ti.com> Cc: nd <nd(a)arm.com> Subject: [TF-M] FW: Pre-provisioned keys Hi Folks, Brian got one question about pre-provisioned keys, anyone could reply? Hi Brian, you can subscribe the mailing list here: https://lists.trustedfirmware.org/mailman/listinfo/tf-m Thanks. /Ken From: Quach, Brian <brian(a)ti.com<mailto:brian@ti.com>> Sent: Wednesday, May 27, 2020 6:36 AM Subject: Pre-provisioned keys Hi Ken, Does TF-M have a plan for storing and accessing persistent keys (such as HUK) installed to flash at the factory prior to provisioning of the device? I had seen these as being stored outside of ITS flash in some compile time defined location and being read-only. Regards, Brian

6 years, 1 month

1
0
0 0

FW: Pre-provisioned keys

by Ken Liu

Hi Folks, Brian got one question about pre-provisioned keys, anyone could reply? Hi Brian, you can subscribe the mailing list here: https://lists.trustedfirmware.org/mailman/listinfo/tf-m Thanks. /Ken From: Quach, Brian <brian(a)ti.com> Sent: Wednesday, May 27, 2020 6:36 AM Subject: Pre-provisioned keys Hi Ken, Does TF-M have a plan for storing and accessing persistent keys (such as HUK) installed to flash at the factory prior to provisioning of the device? I had seen these as being stored outside of ITS flash in some compile time defined location and being read-only. Regards, Brian

6 years, 1 month

1
0
0 0

Re: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM

by Jamie Fox

Hi Ken, Many similar abstractions for compiler C language extensions are provided by cmsis_compiler.h, already copied into the TF-M code base. If it does not meet all of our needs, should we consider proposing improvements to the upstream CMSIS project? Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 25 May 2020 05:02 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Compiler related] Unify necessary and minimal set compiler definitions for SPM Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

6 years, 1 month

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - May 28

by Edison Ai

Hi Anton, I want to give an introduction about the HAL for TF-M core, about 30 mins. Thanks, Edison From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Tuesday, May 19, 2020 9:46 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - May 28 Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 28 May 2020, 07:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

6 years, 1 month

1
0
0 0

by Ken Liu

Hi, We created a proposal to define a minimal set of compiler specific-definitions for SPM. The reason is to avoid many #ifdef inside SPM code. Only limited definitions are defined. Platform sources need to use platform defined headers for these definitions, such as CMSIS headers. Special usage such as 'weak' or 'noreturn' are forbidden inside SPM. Please put comments for this change: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4211 Or reply here. This is just an example patch, the follow up would apply this defined headers to all SPM sources. Thanks /Ken

6 years, 1 month

1
0
0 0

Simplify the veneers of library model

by Mingyang Sun

Hi all, In the current implementation, every secure function has an associated veneer function. Therefore, there are so many veneer functions in ‘tfm_veneers.c’, which have a similar prototype. This would lead to: * Waste of the veneer and secure function size – these APIs have a similar prototype, and they have unified NS dispatcher already. * More secure functions lead to more veneers and potential re-configuration of the non-secure callable area. This patch tries to unify the service entry so that: * Similar function codes do not need to be duplicated. * Keeping almost the same performance. This is also an experiment patch to start the journey to the SFN model Andrew proposed. Let’s see the feedbacks and decide what to do in the next step. https://review.trustedfirmware.org/c/trusted-firmware-m/+/4115 Please do feedback, especially the library model users – please check what kinds of the inconvenience it brings so that we can discuss the correct shape. Here are some details in the patch: Prototype of the unified veneer function: psa_status_t tfm_sfc_call(uint32_t ctrl, psa_invec *in_vec, psa_outvec *out_vec); where: the uint32_t type parameter ‘ctrl’ is a pack of parameters - psa invec length, psa outvec length, and function identifier. [8 bits for inlen][8 bits for outlen][16 bits for function identifier] This is to avoid the condition that 5 parameters will cause re-wrapping of parameters. Time cost and code size measurement: github-tracking Use the unified veneer cost of a veneer call is 1264 cost of an interrupt is 941 veneer used 832B, region size 832B, 100% cost of a veneer call is 1274 cost of an interrupt is 941 veneer used 64B, region size 832B, 7.69% Thanks, Mingyang

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M and provisioning

by Shebu Varghese Kuriakose

Hi Gernot, Provisioning was added as a future roadmap item in anticipation of a PSA Provisioning Specification. The Specification (Factory or application specific) hasn't happened so far. There is no active work ongoing in TF-M around provisioning. TF-M using provisioned keys in CC-312 on MuscaB1 platform is available as an example. See details here<https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…> under CC312 heading. In TrustedFirmware TSC, provisioning has been a discussion topic sometime back. Search for provisioning in the minutes below. https://github.com/microbuilder/certificate_chains/blob/master/rfc_tfm.md is an RFC that Kevin prepared during those discussions for TF-M devices to use certificate chain. Regards, Shebu https://lists.trustedfirmware.org/pipermail/tsc/2019-September/000044.html https://lists.trustedfirmware.org/pipermail/tsc/2019-October/000048.html https://lists.trustedfirmware.org/pipermail/tsc/2019-November/000052.html https://lists.trustedfirmware.org/pipermail/tsc/2019-December/000068.html https://lists.trustedfirmware.org/pipermail/tsc/2020-January/000072.html https://lists.trustedfirmware.org/pipermail/tsc/2020-February/000076.html -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gernot Kvas via TF-M Sent: Tuesday, May 19, 2020 10:03 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M and provisioning Hello, I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2]. What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated. Thanks for your help & kind regards, Gernot [1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf [2] https://developer.trustedfirmware.org/w/tf_m/planning/ -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

TF-M and provisioning

by Gernot Kvas

Hello, I would like to understand the background behind roadmap item "Provisioning" that is mentioned here [1] (Slide 31) and here [2]. What provisioning functionality would we be talking here, is it provisioning as in "RoT provisioning", so more towards manufacturing as defined in the PSA security lifecycle, or provisioning when the device is in state "Secured", so more towards application specific-data? I would assume the latter, but couldn't find any more information on this subject. Any pointers would be highly appreciated. Thanks for your help & kind regards, Gernot [1] https://static.linaro.org/connect/san19/presentations/san19-203.pdf [2] https://developer.trustedfirmware.org/w/tf_m/planning/

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - May 14

by Anton Komlev

Ups, please ignore this invitation with outdated subject. I have sent a better one. Sorry for confusion. Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 19 May 2020 13:58 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M Technical Forum call - May 14 Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 28 May 2020, 07:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

6 years, 1 month

1
0
0 0

TF-M Technical Forum call - May 28

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 28 May 2020, 07:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

6 years, 1 month

1
0
0 0

TF-M Technical Forum call - May 14

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, May 28 at 6:00-7:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Here are some local time examples: Location Local Time Time Zone UTC Offset Vancouver<https://www.timeanddate.com/worldclock/canada/vancouver> (Canada - British Columbia) Wednesday, 27 May 2020, 23:00:00 PDT<https://www.timeanddate.com/time/zones/pdt> UTC-7 hours Chicago<https://www.timeanddate.com/worldclock/usa/chicago> (USA - Illinois) Thursday, 28 May 2020, 01:00:00 CDT<https://www.timeanddate.com/time/zones/cdt> UTC-5 hours Cambridge<https://www.timeanddate.com/worldclock/uk/cambridge> (United Kingdom - England) Thursday, 28 May 2020, 07:00:00 BST<https://www.timeanddate.com/time/zones/bst> UTC+1 hour Shanghai<https://www.timeanddate.com/worldclock/china/shanghai> (China - Shanghai Municipality) Thursday, 28 May 2020, 14:00:00 CST<https://www.timeanddate.com/time/zones/cst-china> UTC+8 hours Corresponding UTC (GMT) Thursday, 28 May 2020, 06:00:00<https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200528T0600> Best regards, Anton Komlev

6 years, 1 month

1
0
0 0

Re: [TF-M] PSA documentation page

by Ken Liu

Now we linked the home page (https://developer.arm.com/architectures/security-architectures/platform-sec…) of PSA in the readme (https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBu…), are you proposing to update to this documentation link? /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Adrian Shaw via TF-M Sent: Monday, May 18, 2020 6:12 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] PSA documentation page For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

6 years, 1 month

1
0
0 0

[RFC] Compiler-specific configurations and architecture registers

by Summer Qin

Hi, Even the ongoing HAL design abstracts all platform-specific operations, there are still some operations that need to be performed directly in TF-M, such as architecture-related operations. These operations are common for all platforms, such as: * generic assembler code for AAPCS based context management. * assign attributes to specific functions. These operations rely on compiler and architecture much instead of the platform. So, define a CORE-specific compiler configuration header file would be a straight requirement. With these unified headers, writing the architecture-specific code would be much safer because it won't involve hardcode compiler related changes. The minimal set of mandatory architecture registers is also planned to be defined. Here send out a mail to collect for the feedbacks - is it worthy of doing this to decouple the architecture from the platform, or we can just re-use the platform provided headers? Any comments are welcome:) Best Regards, Summer

6 years, 1 month

1
0
0 0

PSA documentation page

by Adrian Shaw

For anyone who is interested in a more comprehensive list of the PSA documents, the following page is now available on developer.arm.com that lists the documents, the latest specification versions and their current quality status. https://developer.arm.com/architectures/security-architectures/platform-sec… Best, Adrian

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M