- TF-M - lists.trustedfirmware.org

Re: [TF-M] Firmware update API - MCUboot update

by Andrew Thoelke

Hi Suresh, > I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. Are you suggesting that the software stack might look like this: Update client application | | Function call V MCUBoot user API Shim layer | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot user API MCUBoot engine This looks like it has one more layer than it needs, as either: 1. The Update client application could Talk directly to the FWU API, or 2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose. Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update Hi Sherry, Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API. Details that would help: 1. How the MCUboot works without the FWU API - natively 2. How the MCUBoot needs to be modified to leverage from FWU API 3. What components are retained in MCUBoot ex: image format, signing, metadata, tools I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like? thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>. We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Can you please provide more specific suggestion or questions? Regards, Sherry Zhang From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Hi Sherry, Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Firmware update API - MCUboot update Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 8 months

2
1
0 0

Re: [TF-M] Firmware update API - MCUboot update

by Sherry Zhang

Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Firmware update API - MCUboot update Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 8 months

2
4
0 0

Re: [TF-M] A question on tfm its filesystem

by David Hu

Hi Poppy, SPRT requires the shared library shall not own static R/W data. ITS filesystem may not satisfy this requirement. Usually, a SP, for example Protected Storage, can rely on ITS service to access data in non-volatile memory. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Monday, May 24, 2021 12:54 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on tfm its filesystem Hi, I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm. Therefore,besides its partition, other extra secure partitions can also make use of this filesystem. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 8 months

2
2
0 0

Wiki page sorting out

by Ken Liu

Hi, There are some out of sync contents in the wiki page (mainly the design chapter), which needs to be cleaned a bit. https://developer.trustedfirmware.org/w/tf_m/ As the first step, the following article would be removed (Would move to a recyclable place at first): Cooperative Scheduling Rules - content out of date. Non-Secure Interrupt Handling - covered in the design document. Secure Partition Interrupt Handling - covered in the interrupt handling document. Service IPC compatibility - Attestation - low priority, no need to be a standalone item. Service IPC compatibility - SST - same as above. Trusted Firmware-m Isolation Level 2 - covered by document 'FF-M isolation'. Uniform Secure Service Signature - out of date, as most of related files are changed. Any comments please feel free to ping me. Would do this on Thursday (27th May) this week. Thanks. /Ken

4 years, 8 months

1
0
0 0

A question on tfm its filesystem

by Edward Yang

Hi, I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm. Therefore,besides its partition, other extra secure partitions can also make use of this filesystem. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 8 months

1
0
0 0

Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent

by Gyorgy Szing

Hi, Just a guess, but the "UNINIT" attribute described here [1] might be the one you are looking for. [1] https://developer.arm.com/documentation/100070/0612/scatter-file-syntax/exe… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 21 May 2021 03:22 To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Hi Suresh, Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo… I believe they can provide a more comprehensive answer. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, May 21, 2021 12:13 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 8 months

1
0
0 0

Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent

by David Hu

Hi Suresh, Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo… I believe they can provide a more comprehensive answer. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, May 21, 2021 12:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 8 months

1
0
0 0

A question on Arm linker - GCC NOLOAD equivalent

by Suresh.Marisetty＠infineon.com

Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 8 months

1
0
0 0

Tentative future TF-M release dates

by Shebu Varghese Kuriakose

Hi All, As many might know, TF-M is now making release tags around every 4 months as defined here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…>. In order to help contributors and users of Trusted Firmware-M releases, the code freeze and release dates of the next 2 releases are published here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…> (TF-M -> Docs -> Future release plans) Note that these dates are tentative and can shift if issues are identified leading upto the release. Regards, Shebu

4 years, 8 months

1
0
0 0

Technical Forum call - May 27

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 27 , 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 8 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M