- TF-M - lists.trustedfirmware.org

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark 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: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M 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/>

4 years, 11 months

1
0
0 0

TF-M openCI nightly notification mail list is ready to subscribe

by Karl Zhang

Hi, There is a CI notification mail list enabled, it aims to send the failure info of TF-M nightly job to the subscribers without spam to a big group. If you are interested in the master branch nightly verification status, feel free to add your email to the list. Subscribing: https://lists.trustedfirmware.org/mailman/listinfo/tf-m-ci-notifications The notification only triggers a notification when CI build or test fail occur from the nightly job. Thanks Karl

4 years, 11 months

1
0
0 0

IAR, problems building with 8.50.9

by Thomas Törnblom

IAR released a new service pack late last week, version 8.50.9. This service pack includes a new compiler version, which although thoroughly tested, apparently introduced a new intricate bug, which causes at least the musca_a mcuboot to fail. The issue has been identified and fixed, and the next release should have this fix. I have no date for when this will be released or in what form. So for the time being, please do not upgrade above version 8.50.7. Thanks, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

4 years, 11 months

1
0
0 0

[RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

Hi, We are now allocating partition's stack inside linker script file, and there are two external patches trying to move these stack definitions into partition's BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other - actually we don't apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

4 years, 11 months

1
0
0 0

[RFC] Build: Move UART symbols to SPRTL

by Kevin Peng

Hi Platform owners, explicitly ST, Nordic and NXP owners. Could you confirm that this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6678> wouldn't break your platforms. The patch changes the build system to put the UART drivers to the SPRTL. It is important to improve the isolation implementations. For more details, please see the patch. We will wait for one more week and merge it as is if no feedbacks. Any feedbacks from others are welcome always. Best Regards, Kevin

4 years, 12 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Secure Enclave solution in TF-M 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/>

4 years, 12 months

1
0
0 0

Review request of TF-M dual-cpu mailbox enhancement

by David Hu

Hi all, Could you please help the patches to enhance TF-M dual-cpu mailbox, as discussed in last Technical Forum? Improvements to make NS RTOS port easier: https://review.trustedfirmware.org/q/topic:%22mailbox-enhance%22+(status:op… A new working model to support NS RTOS application isolation better: https://review.trustedfirmware.org/q/topic:%22mailbox-dedicated-thread%22+(… Any comment is welcome! Please see the slides for the basic ideas of the enhancements mentioned above. Slides link: https://www.trustedfirmware.org/docs/TF-M_Dual-cpu_NSPE_mailbox_enhancement… Best regards, Hu Ziji

4 years, 12 months

1
0
0 0

Re: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M

by Jamie Fox

Hi, Thank you for the proposal, I have commented in the Gerrit review. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 December 2020 14:28 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> ======================================================== CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 12 months

1
0
0 0

TF-M Technical Forum call - December 10

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, December 10 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

4 years, 12 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301 It was simpler than I had thought :) Øyvind From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, November 26, 2020 07:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no<mailto:Torsten.Rasmussen@nordicsemi.no>> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

4 years, 12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M