- TF-M - lists.trustedfirmware.org

Re: [TF-M] platform-specific hw initialization

by Ken Liu (Arm Technology China)

Hi Andrei, I have taken a look at give some tiny comment -- the idea is good for now since some extra platform initialization is needed. Thanks /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: Friday, September 27, 2019 1:00 AM To: Andrei Narkevitch <Andrei.Narkevitch(a)cypress.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] platform-specific hw initialization Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. > -- > 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

6 years, 9 months

1
0
0 0

Re: [TF-M] platform-specific hw initialization

by Kevin Townsend

Hi Andrei, This would solve a problem that we currently have with UART with Zephyr, and seems like a useful addition. Thanks for putting the change request together. Kevin On Thu, 26 Sep 2019 at 09:48, Andrei Narkevitch via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi All, > > We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. > Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. > https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 > > Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? > > Thanks, > Andrey Narkevitch > Cypress Semiconductor > > This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

platform-specific hw initialization

by Andrei Narkevitch

Hi All, We're proposing to add an API that would allow to implement a custom post-startup initialization of hw, peripherals etc. Contrarily to SystemInit() intended for a high priority hw initialization (for example clock and power subsystems), and called on a very early boot stage from startup code, these functions are called from C code, hence variables and other drivers data are protected from being cleared up by the C library init. https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973 Ken and Mate, as maintainers of the TF-M core part, could you please take a look at the patch? Thanks, Andrey Narkevitch Cypress Semiconductor This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Robert Rostohar

Hi Mate, Thanks for the detailed explanation and confirmation that the SAU region number reference can be removed. This will enable using CMSIS-Zone to configure also TF-M in an easy way. I would appreciate if some can create a ticket to track progress. Thanks, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M Sent: Thursday 26 September 2019 09:40 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment 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. -- 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 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.

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

by Mate Toth-Pal

Hi Robert, The region IDs in 'tfm_ns_region_e' are used for two purposes in TF-M (just as you mention in your mail): 1. For configuring the SAU. As far as I understood, with the CMSIS-Zone Utility it is possible to generate a 'tz_sau_nvic.c' file, which then can be added to the platform folder of a target in TF-M. The tfm_spm_hal_init_isolation_hw(...) hal function then can call the TZ_Config_SAU(...) function defined in 'tz_sau_nvic.c'. The TZ_Config_SAU(...) uses integer literals to address the different regions of the SAU, but that is OK for this purpose. 2. The tfm_core_memory_permission_check_handler(...) function The idea was that secure services would be able to query whether the caller NS client has access to a certain NS memory region. Implementing this feature would require TF-M core to know whether a region returned by cmse_check_address_range is a Non-Secure memory or not. With the current output of the CMSIS-Zone Utility I don't see this is possible other than looking into the config of the SAU region and check the content of the RLAR register. (Although this would only reveal whether the region is S/NS, code/data differentiation should be done in a different way) However this feature never got implemented, and this is only supported in Library model. Also after removing isolation level 3 from Library model I think there is no point in keeping this function. So the reference to the SAU regions from this function can be removed. So summarizing the above, I think there is no reason why CMSIS-Zone Utility could not be used in TF-M, and it seems that it could be integrated fairly easily. Regards, Mate -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 26 September 2019 09:27 To: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment Hi Summer, Thanks for looking into this. Requesting a specific SAU region number for a specific memory region is an inconvenience for CMSIS-Zone. It introduces additional complexity for the user who would need to know and configure this and also for the tool to handle. Normally the user just configures the memory region (address, size, access. security, privilege, ...) and leaves to the tool to assign a region and generate the SAU setup code. Having the additional constrain (ex: NS_CODE needs to be assigned to RGN=0) is just another obstacle and source of error in user configuration of the memory layout for TF-M. I would help if TF-M would remove the constrain on specific region number assignments. Thanks, Robert -----Original Message----- From: Summer Qin (Arm Technology China) <Summer.Qin(a)arm.com> Sent: Thursday 26 September 2019 08:14 To: Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Zone Alignment 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. -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Zone Alignment

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.

6 years, 9 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

6 years, 9 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

6 years, 9 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.

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 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

6 years, 9 months

1
0
0 0

[RFC] Manipulate connection handle value

by Ken Liu (Arm Technology China)

Hi, I have created a patch to manipulate the handle value returned to caller. At first when we was implementing IPC we created an unique id for handle, the price is we need to loop searching for the data structure from the list with this id, which increases the execution time. Then we optimized this part return the memory allocated directly - since the memory is protected by hardware, the memory content could not be retrieved, either. But to avoid the potential information leakage or some side channel attack on handles, we need to disturb it before return to user. The returned handle contains only limited information so that it makes user hard to retrieve information on it. Now the returned value is the offset inside handle pool, without showing the memory address directly. This can be enhanced later after the random generator is applied, we can disturb more on this part. The patch is here: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1962 Please help to comment in this thread or in the issue tracker: https://developer.trustedfirmware.org/T501 Thanks. /Ken

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Andrej Butok

"non-make based systems which are commonly used for microcontroller development" This message must understand every TF-M developer! -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Monday, September 16, 2019 7:14 AM To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com>; Jamie Fox <Jamie.Fox(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Antonio, Jamie, Thanks both for the explanations. It is understood how crypto headers are handled in TF-M and why. However this approach is causing issues when using non-make based systems which are commonly used for microcontroller development. I have explained already what the issue is and Andrej provided even more details in T428. Please keep track of all issues that have been reported initially in this thread. Thanks, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday 13 September 2019 09:08 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Antonio, If you do not want to change the file name, could you at least change the include name? For example, from #include "psa/crypto.h" to #include "tfm/psa/crypto.h" It works in our port. Is it possible for you? Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, September 12, 2019 10:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…);reserved=0), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Robert Rostohar

Hi Christian, TF-M has solved this by adding mbedcrypto__ prefix to PSA functions implemented with mbed-crypto (see header crypto_spe.h). This works also when using component based system, besides the issue with headers discussed in this thread. Best regards, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Christian Daudt via TF-M Sent: Saturday 14 September 2019 16:18 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, I'm failing to see how TFM and mbed-crypto can be both components in a TF-M system. I would expect that when I call e.g. "psa_import_key " from the NSPE, that must resolve to a single implementation, and it must be the TF-M client api that passes the request to the SPE crypto service - i.e. the code from interface/src/tfm_crypto_*_api.c. Can you describe how you see both being utilized simultaneously? Thanks, Christian. On 2019-09-13, 3:07 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi Antonio, If you do not want to change the file name, could you at least change the include name? For example, from #include "psa/crypto.h" to #include "tfm/psa/crypto.h" It works in our port. Is it possible for you? Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, September 12, 2019 10:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…);reserved=0), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message. -- 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.

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Robert Rostohar

Hi Antonio, Jamie, Thanks both for the explanations. It is understood how crypto headers are handled in TF-M and why. However this approach is causing issues when using non-make based systems which are commonly used for microcontroller development. I have explained already what the issue is and Andrej provided even more details in T428. Please keep track of all issues that have been reported initially in this thread. Thanks, Robert -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: Friday 13 September 2019 09:08 To: Antonio De Angelis <Antonio.DeAngelis(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Antonio, If you do not want to change the file name, could you at least change the include name? For example, from #include "psa/crypto.h" to #include "tfm/psa/crypto.h" It works in our port. Is it possible for you? Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, September 12, 2019 10:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…);reserved=0), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- 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.

6 years, 9 months

1
0
0 0

[RFC] Update on Secure Partition Runtime Library design document

by Ken Liu (Arm Technology China)

Hi, I was trying to fix some typos in this document before, so I just create a short commit; but after couple times of updating I added more content into it, so called a review on this part. The changed part is, involving the RoT Service API implementation into SPRTL to simplify the caller usage. The RoT Service API is proposed in PSA FF 1.0.0, and I think this is the ideal place for putting it. The link: https://review.trustedfirmware.org/c/trusted-firmware-m/+/1886 Thanks. /Ken

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Christian Daudt

Hi Robert, I'm failing to see how TFM and mbed-crypto can be both components in a TF-M system. I would expect that when I call e.g. "psa_import_key " from the NSPE, that must resolve to a single implementation, and it must be the TF-M client api that passes the request to the SPE crypto service - i.e. the code from interface/src/tfm_crypto_*_api.c. Can you describe how you see both being utilized simultaneously? Thanks, Christian. On 2019-09-13, 3:07 AM, "TF-M on behalf of Andrej Butok via TF-M" <tf-m-bounces(a)lists.trustedfirmware.org on behalf of tf-m(a)lists.trustedfirmware.org> wrote: Hi Antonio, If you do not want to change the file name, could you at least change the include name? For example, from #include "psa/crypto.h" to #include "tfm/psa/crypto.h" It works in our port. Is it possible for you? Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, September 12, 2019 10:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…);reserved=0), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

6 years, 9 months

1
0
0 0

Re: [TF-M] Signing merged single image with dual keys

by Tamas Ban

Hi Kevin, Recently there are two major change in TF-M MCUBoot: - images signed separately with different keys and concatenated after to make one blob. It drives by MCUBOOT_IMAGE_NUMBER (default is 2 on AN521) - It's possible to use keys from HW and not hard-code the public key to the MCUBoot code at compile time. It derives by MCUBOOT_HW_KEY (default is True on AN521) - You can check the bl2/ext/mcuboot/MCUBoot.cmake two see how the scripts are invoked, which order, what kind of attributes. Additional info is in docs/user_guide/tfm_secure_boot.rst You can revert back to previous behaviour, single(S+NS) signed image(key is: *3072.pem) and public-key is embedded in MCUBoot code base with setting MCUBOOT_IMAGE_NUMBER=1 and MCUBOOT_HW_KEY=False Tamas -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M Sent: 13 September 2019 11:48 To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Signing merged single image with dual keys Hi, Updating to the latest code in the TF-M repo, I noticed that there are now two separates keys for signing images: - *3072.pem for the S image - *3072_1.pem for the NS image It's not clear to me how to make this work with a single merged image, which is what we generally need, with an IPC-based system where the S image is generated via the TF-M repo and the NS image in Zephyr, making calls to the S services via the PSA APIs. Previously, we used the ASSEMBLE.PY tool in BL2 to merge the TF-M S and Zephyr NS images, outputting a single binary that we then signed via IMGTOOL.PY using the default or user-defined .pem file. This no longer works, and any attempt to use a binary generated via this method results in: [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [ERR] Authentication failed! Image in the primary slot is not valid. [ERR] Unable to find bootable image With the latest dual-key TF-M code, when we build the TF-M repo, we get an S image that is signed using the 3072.pem key, but after a bit of trial and error I haven't found the secret handshake on how to sign the NS image and merge them into a single binary and then copy them over to the MPS2+ (or other HW) and have the BL accept them at startup. Any pointers on how to generate a single merged image with both parts signed using the different keys, or am I going about this the wrong way? Kevin -- 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.

6 years, 9 months

2
1
0 0

TF-M / CMSIS-Zone Alignment

by Robert Rostohar

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.

6 years, 9 months

1
0
0 0

Signing merged single image with dual keys

by Kevin Townsend

Hi, Updating to the latest code in the TF-M repo, I noticed that there are now two separates keys for signing images: - *3072.pem for the S image - *3072_1.pem for the NS image It's not clear to me how to make this work with a single merged image, which is what we generally need, with an IPC-based system where the S image is generated via the TF-M repo and the NS image in Zephyr, making calls to the S services via the PSA APIs. Previously, we used the ASSEMBLE.PY tool in BL2 to merge the TF-M S and Zephyr NS images, outputting a single binary that we then signed via IMGTOOL.PY using the default or user-defined .pem file. This no longer works, and any attempt to use a binary generated via this method results in: [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [ERR] Authentication failed! Image in the primary slot is not valid. [ERR] Unable to find bootable image With the latest dual-key TF-M code, when we build the TF-M repo, we get an S image that is signed using the 3072.pem key, but after a bit of trial and error I haven't found the secret handshake on how to sign the NS image and merge them into a single binary and then copy them over to the MPS2+ (or other HW) and have the BL accept them at startup. Any pointers on how to generate a single merged image with both parts signed using the different keys, or am I going about this the wrong way? Kevin

6 years, 9 months

1
0
0 0

Re: [TF-M] TF-M / CMSIS-Pack Alignment

by Andrej Butok

Hi Antonio, If you do not want to change the file name, could you at least change the include name? For example, from #include "psa/crypto.h" to #include "tfm/psa/crypto.h" It works in our port. Is it possible for you? Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio De Angelis via TF-M Sent: Thursday, September 12, 2019 10:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, TF-M Crypto and Mbed-crypto are both implementations of the same interface, hence the same header names with different contents. Internally, TF-M Crypto uses Mbed-crypto as a library component, and its include path his hidden into the TF-M build system as Jamie explained, but an user application of TF-M is only able to use and include the TF-M Crypto headers, using the TF-M build system, by including psa/crypto.h If your IDE makes both Mbed-crypto and TF-M Crypto visible to the user application at global level, at build time the IDE must make sure that the right include path is visible, given that the PSA spec currently mandates the name of the header to be included to be psa/crypto.h and neither of the implementations are allowed to rename it without diverging from the spec. /Antonio -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: 12 September 2019 18:53 To: Jamie Fox <Jamie.Fox(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Jamie, The current solution is limiting how TF-M can be used. This is blocking toolchain and silicon vendors for wider adoption of TF-M. I have explained this already to @Ashutosh Singh and he confirmed that this is an issue. Yes, you can prebuild mbed-crypto and use it as a library. However in systems based on software components, TF-M is a component and mbed-crypto also. They are built within a single project with all registered includes.. Having different implementations of an API header with the same name is simply not acceptable when components are global. It would be really good to create a task for each of the issues I have reported in order to track them. I would appreciate if someone from TF-M team can create the tasks and assign to the right person. Thanks, Robert -----Original Message----- From: Jamie Fox <Jamie.Fox(a)arm.com> Sent: Thursday 12 September 2019 18:13 To: Andrej Butok <andrey.butok(a)nxp.com>; Robert Rostohar <Robert.Rostohar(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: TF-M / CMSIS-Pack Alignment Hi Robert, Andrej, Regarding the first point, TF-M and Mbed Crypto are two separate projects, both containing a version of the standard "psa/crypto.h" header. Neither project can remove the header, nor rename it because the name is standardised by the PSA specs. When Mbed Crypto is used as a library by TF-M, we install its PSA headers to "include/mbedcrypto/psa/crypto.h" and then add only the base "include" directory to the include search paths. Then there is no conflict between TF-M and Mbed Crypto headers, because the former can be included with #include "psa/crypto.h" and the latter with #include "mbedcrypto/psa/crypto.h". Only the Crypto service is linked with Mbed Crypto, which it uses as its backend implementation, so that is why it is the only part of TF-M to include Mbed Crypto headers. All other parts of TF-M include the TF-M psa/crypto.h header, which is implemented by service requests to the Crypto service. The only other simple solution I see to this is not to add the Mbed Crypto include directory to the search path at all. Then Mbed Crypto headers would need to be included with #include "mbed-crypto/include/psa/crypto.h" etc. I didn't get chance to read the other issues yet, but maybe it would be easier to create a task for each one on Phabricator (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper…);reserved=0), so that we can keep track of the discussion and work for each issue more easily? Best wishes, Jamie -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 12 September 2019 11:52 To: Robert Rostohar <Robert.Rostohar(a)arm.com> Cc: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M / CMSIS-Pack Alignment Hi Robert, Great! I gave up to convince about the first point https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper… As you are from ARM, hope, you will able to push through all your improvements. Thanks, Andrej Butok -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Robert Rostohar via TF-M Sent: Thursday, September 12, 2019 12:34 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] TF-M / CMSIS-Pack Alignment Hi, We are looking into providing TF-M as a CMSIS-Pack [1] and have discovered a few issues in TF-M that are currently blocking us. 1. Crypto headers ./interface/include/psa clash with headers from mbed-crypto .include/psa It seems that TF-M copies the crypto headers from mbed-crypto folder ./include/psa into folder ./mbedcrypto/psa. However TF-M also provides different crypto headers in folder ./interface/include/psa. TF-M modules typically include "psa/crypto.h" except crypto service modules which include "mbedcrypto/psa/crypto.h" through "tfm_mbedcrypto_include.h". The problem is that in our tools both include folders (./include from mbed-crypto installation and ./interface/include from TF-M) are in the global search path causing wrong headers being used. Another issues is the use of "mbedcrypto" prefix in include "mbedcrypto/psa/crypto.h". We have mbed-crypto already installed and copying crypto headers would not be needed when using include "psa/crypto.h". 1. Device header TF-M currently uses "cmsis.h" as the device header. This is not compliant with CMSIS [2] which defines the naming convention for device headers, startup files and system configuration files. Silicon vendors typically define header filenames that match their device names. The device agnostic way proposed by CMSIS is to use a preprocessor define CMSIS_device_header that reflects the actual device name and is provided by the build environment. We suggest to replace: #include "cmsis.h" with: #include CMSIS_device_header This would affect the following modules: ./secure_fw/core/arch/tfm_arch_v8m_base.c ./secure_fw/core/arch/tfm_arch_v8m_main.c ./secure_fw/core/arch/include/tfm_arch.h ./platform/ext/target: various target files 1. Conditional inclusion of secure services: Storage, Crypto, Attestation Our concept is based on software components and we have described each secure service as a single component that is user selectable. This requires conditional inclusion of a secure service based on preprocessor definitions. TF-M already supports this for secure services Audit Logging (#ifdef TFM_PARTITION_AUDIT_LOG) and Platform (#ifdef TFM_PARTITION_PLATFORM) and also for all test services (#ifdef TFM_PARTITION_TEST_...). We suggest to add this also to secure services Storage (#ifdef TFM_PARTITION_STORAGE), Crypto (#ifdef TFM_PARTITION_CRYPTO) and Attestation (#ifdef TFM_PARTITION_INITIAL_ATTESTATION). This would affect the following modules: ./secure_fw/services/tfm_partition_defs.inc ./secure_fw/services/tfm_service_list.inc ./secure_fw/services/tfm_spm_db.inc ./secure_fw/ns_callable/tfm_veneers.c ./interface/include/tfm_veneers.h We are aware that those file are supposed to be autogenerated however we use them directly at this point. Adding the mentioned preprocessor defines should be trivial and would unblock us. 1. Conditional inclusion of individual test suites We have described also test suites as individual components that are user selectable. This requires conditional inclusion of test suites based on preprocessor definitions. TF-M already supports this for some test suites (#ifdef ENABLE_AUDIT_LOGGING_SERVICE_TESTS, ...). We suggest to add this also for all other test suites. Adding conditional inclusion for secure test suites: ./test/framework/secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS Adding conditional inclusion for non-secure test suites: ./test/framework/non_secure_suites.c #ifdef ENABLE_SECURE_STORAGE_SERVICE_TESTS #ifdef ENABLE_CRYPTO_SERVICE_TESTS #ifdef ENABLE_INITIAL_ATTESTATION_SERVICE_TESTS #ifdef ENABLE_QCBOR_TESTS 1. Deprecated Invert Test suite Invert test suite seems to be deprecated. Tests do nothing and just return. It would make sense to remove it. When we expose it as a component to the user it unnecessary increases the complexity of having another component that does nothing. 1. Tests on non-secure side include headers from secure side Non-secure software should not include any secure side internal headers (ex: from ./secure_fw/core/include) but only those that are exposed as APIs (./interface/include). The following test suites on the non-secure side include internal headers from secure side: Attestation: attestation_ns_interface_testsuite.c #include "secure_fw/services/initial_attestation/attestation.h" Core Positive: core_ns_positive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h #include "tfm_plat_test.h // from ./platform/include Core Interactive: core_ns_interactive_testsuite.c #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h ./app/tfm_integ_test.c: #include "test/test_services/tfm_core_test/core_test_defs.h" #include "tfm_core.h" // from ./secure_fw/core/include through core_test_defs.h This actually causes a compile error in our build because tfm_core.h defines the LOG_MSG macro (through secure_utilities.h) which clashes with the inline static function LOG_MSG defined in tfm_integ_test.h. We had to patch the tfm_integ_test.c by adding #undef LOG_MSG after the secure header is indirectly included. ./app/main_ns.c: #include "target_cfg.h" // from ./platform/ext/target/<target_name> target_cfg.h from secure side also contains USART driver definitions for non-secure side. This should be decoupled and non-secure side should not include that header. 1. Dummy platform files ./platform/ext/target/<target_name>/dummy_boot_seed.c ./platform/ext/target/<target_name>/dummy_crypto_keys.c ./platform/ext/target/<target_name>/dummy_device_id.c ./platform/ext/target/<target_name>/dummy_nv_counters.c ./platform/ext/target/<target_name>/attest_hal.c Dummy platform files are intended for testing only and provide a quick way of starting to test TF-M even when the platform files are not yet ported to the platform that the customer using. They are identical and duplicated for all existing targets. We propose to remove the mentioned dummy files from each target and put them in a single folder (./platform/ext/target/template). This simplifies maintenance of the files and also provides a single location of those files that are being used as a platform independent component. 1. Console via USART Console on secure side is retargeted to CMSIS USART driver (./platform/ext/common/uart_stdout.c). USART driver Send function is called also from SVC with highest interrupt priority which blocks the USART interrupt and leads to deadlock. This is not manifested with Musca USART drivers which implement blocking send - not compliant with CMSIS USART Driver [3]. It does occur instantly with any other CMSIS compliant USART driver. As far as I understand the console on secure side will be redesigned to cope with that. There are also other issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. Console on non-secure side is also retargeted to CMSIS USART driver (./app/main_ns.c) however has less constrains. It has the same issues with using the USART driver: * missing wait while busy after send * missing power on/off This is being address with: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr… It also tries to address printf retargeting issues however this needs another iteration. 1. USART driver implementations for platforms included in TF-M As already mentioned all USART drivers implemented for various platforms included in TF-M are not compliant with CMSIS USART Driver specification [3]. They implement blocking send/receive and no power on/off. Drivers should be rewritten and should pass the CMSIS Driver Validation [4]. Please look into the above issues and help us to overcome them. Thanks, Robert [1] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [2] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [3] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… [4] https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.keil.c… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…

6 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M