September 2019 - TF-M - lists.trustedfirmware.org

by Summer Qin (Arm Technology China)

Hi Robert, I think the static defined region number would be much for easier for implementation: First, we need to assign a Region Number together with RBAR and RLAR. Then, we could use the Region Number to stand for the region that is configured by the RBAR and RLAR. It is just like an ID for a block of the memory. Dose it causes some inconvenience for CMSIS-Zone? Regards, Summer On 9/13/19, 6:56 PM, "TF-M on behalf of Robert Rostohar via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi, We are working on CMSIS-Zone Utility [1] which is a GUI tool for configuring a complex system. This includes also TrustZone setup (SAU) and device specific MPC and PPC. This tool can be also used to configure SAU, MPC and PPC in TF-M. However TF-M currently requires that a specific region number is used for NS_REGION_CODE (0), NS_REGION_DATA (1), ... Those region numbers are used when SAU is configured in function sau_and_idau_cfg and the code in function tfm_core_memory_permission_check_handler depends on it. Is it really necessary that a specific region number is being used and why? I have received indication that this in not really needed and that the code should be redesigned. This would enable the use of CMSIS-Zone to configure TF-M out of the box. Thanks, Robert [1] https://github.com/ARM-software/CMSIS-Zone IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

2
1
0 0

Please continue reviewing the merging patches from feature-twincpu branch

by David Hu (Arm Technology China)

Hi all, Sorry for frequent review requests of merging feature-twincpu back. To avoid making it more annoying, I combine three topics here. Please check the details below. 1. NS part changes NSPE mailbox, NS PSA client call interface in multi-core topology, mailbox initialization in NS App main(). https://review.trustedfirmware.org/q/topic:%22twincpu-merge-ns%22+(status:o… 2. Multi-core memory access check Multi-core specific memory access check since multi-core platform cannot rely on the memory check provided by CMSE. A dedicated design document is uploaded, which has been reviewed and accepted on feature-twincpu branch https://review.trustedfirmware.org/q/topic:%22twincpu-merge-mem-check%22+(s… 3. Changes to linker script Several changes to linker script to enable multi-core build: Adjust secure data sections layout to save MPU region and memory resource on Armv6-M/Armv7-M Add a RAM code section to support running code from RAM. https://review.trustedfirmware.org/q/topic:%22twincpu-merge-link-script%22+… This should be the last review request/last merge step before pushing specific multi-core platform support, I promise, at least in Sept. 😊 Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Tuesday, September 24, 2019 2:07 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review the changes to TF-M core/SPM and mailbox from feature-twincpu branch Hi all, Here is the forth step of merging feature-twincpu back to master branch. It includes the changes to TF-M core/SPM and SPE mailbox implementation. Please help review the patches via https://review.trustedfirmware.org/q/topic:%22twincpu-merge-core-mailbox%22… I planned to split those features into multiple topics but failed due to the dependencies between them. They are the key part of multi-core communication, plus the NS mailbox part. I'd like to introduce the components a little bit below. 1. Common PSA client call handlers Multi-core topology invokes PSA client call via mailbox, rather than by calling veneers. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2019/ extracts out common PSA client call handlers from existing svcalls. Single-Armv8-M and multi-core topology can implement their own PSA client call functions respectively and invoke the common PSA client call handlers. 2. Remote Procedure Call (RPC) RPC layer sits between TF-M SPM and underlying SPE mailbox implementation. It decouples the actual mailbox implementations to TF-M SPM and defines several callbacks for underlying mailbox. 3. SPE mailbox As the name implies, it implements the mailbox functionalities and RPC callbacks in SPE. It also defines mailbox HAL APIs for platforms. The NSPE part mailbox will be uploaded later. 4. Generic multi-core functionalities This part adds several TF-M core functions, with multi-core specific implementations, such as tfm_nspm_thread_entry () and tfm_psa_ipc_request_handler(). Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, September 20, 2019 5:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review topology changes for supporting diverse topology use cases Hi all, Would you please help review the following patches to support multi-core topology in TF-M? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-topology%22+(st… Those patches prepare for multi-core support being merged from feature-twincpu branch to master branch. It is the third step of the merging back progress. The previous steps are multi-core build enhancement and Armv6-M/Armv7-M arch support below. If it sounds interesting to you, I'm glad to share more details about multi-core development and plan of merging it back to master. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, September 19, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review Armv6-M/Armv7-M support patches Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

Re: [TF-M] TF-M Internal Trusted Storage service design proposal

by Jamie Fox

Hi all, The ITS design document has been on review for quite a while now, so I plan to merge it this week. If anyone still wants to make any comments, please do so soon here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 The ITS implementation is also open for review in this series of patches: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1730 Kind regards, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Fox via TF-M Sent: 22 July 2019 12:00 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Internal Trusted Storage service design proposal Hi all, As you may be aware, implementing the PSA Internal Trusted Storage (ITS) APIs is on the TF-M roadmap for this quarter (https://developer.trustedfirmware.org/w/tf_m/planning/). We plan to implement these APIs with a new TF-M Internal Trusted Storage service. The design proposal for the new TF-M ITS service is now available for design review here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1604 . The design is currently in "draft" state, which means further refinements are to be expected, and feedback is welcome. For more information about the PSA ITS APIs themselves, the PSA Storage API document may be downloaded from here: https://pages.arm.com/PSA-APIs Kind regards, Jamie -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

PSoC6 Erase Block Design issue

by Vikas Katariya

Hi, In PSoC6 target, SST block size is configured as 8 flash sectors<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…> (4KB) and we observe the following issues due to that. These are related to the current implementation at the driver and SST layer. 1. Erasing a block. When sst_flash_erase_block() is invoked<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> from Flash File System for PSoC6 target, seeing that it would never be able to erase more than 512 bytes on PSoC6 when SST emulated block is 4KB which is causing flaw in the initialization sequence<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> or any meta block erase operation<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…>. The ideal solution needs to be addressed on SST Layer, as having a possible workaround in the driver layer would not be ideal. 1. Program Data For the write operation, we do have an implementation in driver layer for PSoC target<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…> which takes care of erasing emulated block size of 4KB before write<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/secure_fw/servi…> operation which doesn't seem to be adequate way, as the erase needs to happen at the SST than driver layer of the target. Please post your comments on Task : https://developer.trustedfirmware.org/T497 Patch review request: https://review.trustedfirmware.org/c/trusted-firmware-m/+/2109 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2110 https://review.trustedfirmware.org/c/trusted-firmware-m/+/2111 These patches address the Erase block issue and removes the workaround for PSoC6 target. Further enhances support for future targets with less than 4KB flash sector erase. Thanks & Best Regards, Vikas Katariya IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 2 months

1
0
0 0

Design proposal for HW crypto key integration in TF-M secure boot

by Tamas Ban

Hi all, PSA Trusted Boot and Firmware Update specification requires the support of at least one immutable root of trust public key (ROTPK) for firmware verification. It is beneficial to be able to provision these keys during the factory life-cycle of the device independently from any software components. The current key handling solution in TF-M secure boot does not supports this key provisioning process. MCUBoot requires compile time built-in public key(s) for image verification. The following design proposal addressing this issue: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1453/ Feel free to add any comments you want on the review! BR, Tamas

5 years, 2 months

1
1
0 0

Please review the changes to TF-M core/SPM and mailbox from feature-twincpu branch

by David Hu (Arm Technology China)

Hi all, Here is the forth step of merging feature-twincpu back to master branch. It includes the changes to TF-M core/SPM and SPE mailbox implementation. Please help review the patches via https://review.trustedfirmware.org/q/topic:%22twincpu-merge-core-mailbox%22… I planned to split those features into multiple topics but failed due to the dependencies between them. They are the key part of multi-core communication, plus the NS mailbox part. I'd like to introduce the components a little bit below. 1. Common PSA client call handlers Multi-core topology invokes PSA client call via mailbox, rather than by calling veneers. https://review.trustedfirmware.org/c/trusted-firmware-m/+/2019/ extracts out common PSA client call handlers from existing svcalls. Single-Armv8-M and multi-core topology can implement their own PSA client call functions respectively and invoke the common PSA client call handlers. 2. Remote Procedure Call (RPC) RPC layer sits between TF-M SPM and underlying SPE mailbox implementation. It decouples the actual mailbox implementations to TF-M SPM and defines several callbacks for underlying mailbox. 3. SPE mailbox As the name implies, it implements the mailbox functionalities and RPC callbacks in SPE. It also defines mailbox HAL APIs for platforms. The NSPE part mailbox will be uploaded later. 4. Generic multi-core functionalities This part adds several TF-M core functions, with multi-core specific implementations, such as tfm_nspm_thread_entry () and tfm_psa_ipc_request_handler(). Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Friday, September 20, 2019 5:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review topology changes for supporting diverse topology use cases Hi all, Would you please help review the following patches to support multi-core topology in TF-M? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-topology%22+(st… Those patches prepare for multi-core support being merged from feature-twincpu branch to master branch. It is the third step of the merging back progress. The previous steps are multi-core build enhancement and Armv6-M/Armv7-M arch support below. If it sounds interesting to you, I'm glad to share more details about multi-core development and plan of merging it back to master. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, September 19, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review Armv6-M/Armv7-M support patches Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

Please review topology changes for supporting diverse topology use cases

by David Hu (Arm Technology China)

Hi all, Would you please help review the following patches to support multi-core topology in TF-M? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-topology%22+(st… Those patches prepare for multi-core support being merged from feature-twincpu branch to master branch. It is the third step of the merging back progress. The previous steps are multi-core build enhancement and Armv6-M/Armv7-M arch support below. If it sounds interesting to you, I'm glad to share more details about multi-core development and plan of merging it back to master. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu (Arm Technology China) via TF-M Sent: Thursday, September 19, 2019 4:37 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Please review Armv6-M/Armv7-M support patches Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 3 months

1
0
0 0

Please review Armv6-M/Armv7-M support patches

by David Hu (Arm Technology China)

Hi all, Could you please take a look at the following patch set to add Armv6-M/Armv7-M support? https://review.trustedfirmware.org/q/topic:%22twincpu-merge-arch%22+(status… That patch set merges Armv6-M/Armv7-M support from feature-twincpu branch back to master branch. It is one step of the progress to merge feature-twincpu branch back to master branch. Any suggestion is welcome. Thanks a lot. Best regards, Hu Ziji

5 years, 3 months

1
0
0 0

Re: [TF-M] Removing legacy veneer support from TF-M library model

by Mate Toth-Pal

Hi All, The patches for this change had been merged. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: 26 August 2019 09:24 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Removing legacy veneer support from TF-M library model Hi All, I'm planning to remove the custom veneer support for Library model from TF-M. Please see the proposed patch here: https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/1597/ Ticket for the change is: https://developer.trustedfirmware.org/T439 After this change all secure services must use the automatically generated veneer functions in 'interface/include/tfm_veneers.h', as it is described in the design: https://developer.trustedfirmware.org/w/tf_m/design/uniform_secure_service_… This change doesn't affect the NSPM secure functions ('TZ_.*()' and 'tfm_register_client_id()' ). This change also doesn't affect IPC model at all (i.e. psa api functions). Regards, Mate -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 3 months

1
0
0 0

[Notification] The patches about dual-core building is going to be merged

by Ken Liu (Arm Technology China)

Hi, The patches for supporting dual-core building is going to be merged into 'master' branch. These patches has gone through couple rounds of reviews, if you have some final comments this would be the last chance: https://review.trustedfirmware.org/q/topic:%2522twincpu-build-enhance%2522+… Any feedback out of code review can reply in this mailing thread or related issue linker: https://developer.trustedfirmware.org/T467 Thanks. /Ken

5 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M September 2019