- TF-M - lists.trustedfirmware.org

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Andrej Butok

Please, do not add changes to sources & linker-files which may harm Non-Cmake systems (IDEs). Thanks, Andrej Butok From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Wednesday, September 23, 2020 8:05 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM 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] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org…> [2] https://jinja.palletsprojects.com/en/2.11.x/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjinja.pal…> [3] https://github.com/kblomqvist/yasha<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> 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: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

6 years, 1 month

2
1
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

As cmake is still the build system, let me check the cmake related feature - but need to wait the build system change get merged then we can take a look where to start. BR. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Gyorgy Szing via TF-M Sent: Tuesday, September 22, 2020 4:43 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha 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: 22 September 2020 10:15 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] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

6 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Gyorgy Szing

Hi Ken, I think templating is a good approach here, the current C preprocessor based solution is a very limited implementation of this. I see two main contenders for templating: 1. cmake has built in support for templating with the configure_file() [1] command. This would move ownership of this information info the build scripts, which are the focus point for such info already. A cmake based solution would feel more native to the existing system. On the other hand other solutions might have more features, which could lead to easier to read template files. Also cmake as a template engine is not that widely adopted. 2. jinja2 [2]. A widely adopted and more feature rich templating engine. TF-M already uses it for manifest file handling. I suggest using yahsa [3] instead of a custom pyhton script as the cli frontend though. This could speed up development as long as no complex processing is needed and the templates can be filled based on "simple" values. Which of the above is the best for the task depends on template file readability and on complexity of the task. It could be nice if a clean split could be made, and we could stop using the C preprocessor based processing completely. "Not sure if all these format support #include" The build system works around that by implementing a compiler specific cmake function to add the pre-processing step for compilers not supporting pre-processing out of the box. /George [1] https://cmake.org/cmake/help/v3.18/command/configure_file.html [2] https://jinja.palletsprojects.com/en/2.11.x/ [3] https://github.com/kblomqvist/yasha From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 September 2020 10:15 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Proposal to separate SCT/LD into each platform folder Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM 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] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

6 years, 1 month

1
0
0 0

Re: [TF-M] Proposal to separate SCT/LD into each platform folder

by Ken Liu

Hi, During the level3 prototyping, we found using a unified sct/ld/file would be hard because we are trying to cover platform-specific setting in ONE place. The biggest concern of preventing spreading the LD is: if there are COMMON changes then every platform source needs to be updated. I believe the COMMON change is the arrangement of ARoT and PRoT, those platform-specific things such as CODE_SRAM and MPU alignment issue should not be covered inside the common sct/ld/icf. Not sure if all these format support #include but as we are using a template so it should be possible to put COMMON settings inside a COMMON template and let platform to contain these common part and then add the specific settings. I have a rough idea (see above) and need more investigation, request for ideas/concerns about this part. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shawn Shan via TF-M Sent: Wednesday, August 5, 2020 1:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Proposal to separate SCT/LD into each platform folder Hi all, There are many differences in linker scripts between each platform. Using a common_s.sct/ld makes it too complicated. And at the same time, in order to achieve isolation level 3, the position of the sessions in scatter and linker script file needs to be adjusted. The common linker scripts would be more complicated with isolation L3. So I would like to propose to have dedicated linker scripts for platforms with enough differential arrangements. What's your opinion on this? Best regards, Shawn

6 years, 1 month

1
0
0 0

Linaro Connect Sessions of Interest

by Don Harbin

Hi All, As Linaro Connect starts tomorrow, here are some pointers to sessions that will be of interest related to trustedfirmware.org. - *PSA Secure Partitions in OP-TEE* - Tuesday, September 22nd (1:25-1:50pm UTC) - Speaker: Miklos Balint - Slides available here <https://static.sched.com/hosted_files/lvc20/9a/LVC20-112_PSA_Secure_Partiti…> - *Trusted Firmware Project update* - Tuesday, Sept. 22nd (2:00-2:25pm UTC) - Spreaders: Matteo Carlini, Shebu Kuriakose - Slides available here <https://static.sched.com/hosted_files/lvc20/1e/LVC20-113-Trusted-Firmware-p…> - *Scalable Security Using Trusted Firmware-M Profiles* - Wednesday September 23rd (11.45am – 12.10pm UTC) - Speakers: Shebu Kuiakose, David Want - Slides available here <https://static.sched.com/hosted_files/lvc20/d0/ScalableSecurityUsingTrusted…> - *Enable UEFI Secure Boot using OP-TEE as Secure Partition* - Thursday September 24th (3.45-4.10pm UTC) - Speakers: Sahil Malhotra, Ilias Apalodimas - *Secure Partition Manager (SEL2 firmware) for Arm A-class devices* - Thursday September 24th (4.15-4.40pm UTC) - Speaker: Olivier Deprez - Slides are available here <https://static.sched.com/hosted_files/lvc20/09/LVC20-305-secure-partition-m…> Some general pointers to sessions of potential interest: - Security related topics can be viewed here - Boot architecture topics can be viewed here As a reminder, sign up for tomorrow's event is at Linaro Connect Registration <https://connect.linaro.org/> and is free, so feel free to forward this information on. :) The overall schedule is available at the same link as registration in case you may be interested in other sessions. Best regards, Don

6 years, 1 month

1
0
0 0

Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0)

by Soby Mathew

For the record, I have attached the full log of the PSA Arch Crypto test run on AN521. The SHA of respective repositories are the test run given below: TF-M - 8f895ab8 PSA Arch tests - ee3c463d tf-m-tests - 7789423 mbedtls - tag: mbedtls-2.23.0 There is an additional failure for test "psa_close_key with RSA 2048 keypair" compared to the summary report below. This is due to incorrect build flag propagation for changing the ITS_MAX_ASSET_SIZE. This will be corrected in the following days. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby Mathew via TF-M Sent: 21 August 2020 11:22 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Just an update to this, I have merged the patch which upgrades to the latest mbedTLS tag. The PSA Arch initial attestation test suite fails to build after this merge due to width change of `ecc_curve_t` type. The issue is reported here in PSA Arch test github project : https://github.com/ARM-software/psa-arch-tests/pull/232 The patch for changing the ITS_MAX_ASSET_SIZE is still outstanding and I hope to merge it after a week. Best Regards Soby Mathew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Soby Mathew via TF-M Sent: 11 August 2020 16:24 To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Patch to upgrade crypto service to use latest mbedTLS tag (v2.23.0) Hi Everyone The following patch updates the crypto service in TF-M to use the latest mbedTLS tag v2.23.0. All reviews for the same will be much appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5252/1 With this update, additional PSA APIs psa_hash_compute() and psa_hash_compare() are now supported. There is also another patch for platforms to update the ITS_MAX_ASSET_SIZE when testing with PSA Crypto API compliance test as one of the tests require a larger size: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5253/1 . Could the platform owners review the same and let me know whether the size changes are OK ? With the above patches, the API compliance remains the same as v1.0 Beta 3 and the PSA Crypto compliance test suite gives the below results (as tested on AN521) : ************ Crypto Suite Report ********** TOTAL TESTS : 61 TOTAL PASSED : 42 TOTAL SIM ERROR : 0 TOTAL FAILED : 17 TOTAL SKIPPED : 2 ****************************************** Best Regards Soby Mathes

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Summer Qin

Hi Anton, I'd like to briefly introduce the enhancement of the TF-M initialization flow, about 20 minutes. Regards, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Sherry Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Tuesday, September 15, 2020 3:08 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - September 17 Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

6 years, 1 month

2
1
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Sherry Zhang

Hi Anton, I would like to give a very brief introduction of the integration work of TF-M and FreeRTOS Kernel which has been merged into FreeRTOS. It will take about 10 minutes around. Regards, Sherry From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

6 years, 1 month

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - September 17

by Kevin Peng

Anton, I'd like to give an update on the HAL APIs, around 10 minutes. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, September 9, 2020 11:34 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - September 17 Hello, The next Technical Forum is planned on Thursday, September 17 at 6:00-07: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

6 years, 1 month

1
0
0 0

Secure Enclave solution in TF-M

by Mark Horvath

Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M