Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V
MCUBoot user API ========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image
BR, Tamas
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke Andrew.Thoelke@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application | | Function call V 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
MCUBoot image size is around 60K and
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
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@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 spechttps://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 documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. 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 linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, 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/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto: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@infineon.commailto:Suresh.Marisetty@infineon.com
HI Tamas,
Thanks for the explanation:
MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) When moving is done just jumps to the reset handler of the new image.
1. What does "move" mean in this context. Write the image to the flash in slot-0 and for this to happen and would it need platform specific hardware knowledge/driver and write privileges to secure flash? 2. What about the MCUBoot image format and FWU SUIT CBOR/COSE format dependencies - I believe these are orthogonal, as MCUBoot blob is wrapped by the SUIT? 3. What about the rollback policy and which component enforces it - MCUBoot or the FWU ? 4. Image tools: MCUBoot vs. SUIT clarity would help?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban Tamas.Ban@arm.com Sent: Tuesday, May 25, 2021 7:56 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) Suresh.Marisetty@infineon.com; Andrew Thoelke Andrew.Thoelke@arm.com; tf-m@lists.trustedfirmware.org Cc: nd 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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V
MCUBoot user API ========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image
BR, Tamas
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application | | Function call V 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
MCUBoot image size is around 60K and
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
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@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 spechttps://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 documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. 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 linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, 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/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto: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@infineon.commailto:Suresh.Marisetty@infineon.com
Hi Suresh,
First of all, I recommend to check https://mcuboot.com/ where all MCUboot specific info is available (design, porting guide, supported crypto features, etc, ). Furthermore, there is a slack channel (link from previous website) to ask the community.
1.) "Moving" in this context (default build options) means to swap the images physically in between primary and secondary slot. So, old image goes to secondary slot and new image copied to primary slot. This makes possible reverting a faulty (valid, but non-functional) image and restore device operational status. However, there are many upgrade strategies (overwrite-only, direct-xip, ram-load, etc.) in which case images might not be moved at all, or old image is not preserved. Details in the design documentation. MCUboot relies on a flash driver which is platform dependent, a HAL is defined. MCUboot is executed in secure mode, so it can access to entire flash. The access demand of FWU partition depends on how the secondary slot is configured, it can be S or NS. It is an implementation choice.
2.) MCUboot currently supports only its own custom manifest format (header + metadata in TLV format attached to the image). SUIT support is planned. AFAIK they will be either header + TLV manifest or header + SUIT manifest.
3.) In the current design MCUboot enforce the rollback policy.
4.) Imgtool Python script is support the custom manifest format. I assume when SUIT manifest support will be added then imgtool also will support it.
BR, Tamas
From: Suresh.Marisetty@infineon.com Suresh.Marisetty@infineon.com Sent: 2021. május 25., kedd 17:44 To: Tamas Ban Tamas.Ban@arm.com; Andrew Thoelke Andrew.Thoelke@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Firmware update API - MCUboot update
HI Tamas,
Thanks for the explanation:
MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) When moving is done just jumps to the reset handler of the new image.
1. What does "move" mean in this context. Write the image to the flash in slot-0 and for this to happen and would it need platform specific hardware knowledge/driver and write privileges to secure flash? 2. What about the MCUBoot image format and FWU SUIT CBOR/COSE format dependencies - I believe these are orthogonal, as MCUBoot blob is wrapped by the SUIT? 3. What about the rollback policy and which component enforces it - MCUBoot or the FWU ? 4. Image tools: MCUBoot vs. SUIT clarity would help?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Tuesday, May 25, 2021 7:56 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V
MCUBoot user API ========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image
BR, Tamas
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application | | Function call V 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
MCUBoot image size is around 60K and
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
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@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 spechttps://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 documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. 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 linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, 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/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto: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@infineon.commailto:Suresh.Marisetty@infineon.com
Hi Tamas,
Wondering if anybody is driving supporting SUIT for MCUBoot/imgtools and a potential ETA?
Also, can somebody throw light on the FreeRTOS support that was announced for the FWU API and how the entire flow works top down from RTOS to the baremetal. Has this reference addressed the SUIT issue?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban Tamas.Ban@arm.com Sent: Tuesday, May 25, 2021 11:51 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) Suresh.Marisetty@infineon.com; Andrew Thoelke Andrew.Thoelke@arm.com; tf-m@lists.trustedfirmware.org Cc: nd 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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
First of all, I recommend to check https://mcuboot.com/ where all MCUboot specific info is available (design, porting guide, supported crypto features, etc, ). Furthermore, there is a slack channel (link from previous website) to ask the community.
1.) "Moving" in this context (default build options) means to swap the images physically in between primary and secondary slot. So, old image goes to secondary slot and new image copied to primary slot. This makes possible reverting a faulty (valid, but non-functional) image and restore device operational status. However, there are many upgrade strategies (overwrite-only, direct-xip, ram-load, etc.) in which case images might not be moved at all, or old image is not preserved. Details in the design documentation. MCUboot relies on a flash driver which is platform dependent, a HAL is defined. MCUboot is executed in secure mode, so it can access to entire flash. The access demand of FWU partition depends on how the secondary slot is configured, it can be S or NS. It is an implementation choice.
2.) MCUboot currently supports only its own custom manifest format (header + metadata in TLV format attached to the image). SUIT support is planned. AFAIK they will be either header + TLV manifest or header + SUIT manifest.
3.) In the current design MCUboot enforce the rollback policy.
4.) Imgtool Python script is support the custom manifest format. I assume when SUIT manifest support will be added then imgtool also will support it.
BR, Tamas
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: 2021. május 25., kedd 17:44 To: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Firmware update API - MCUboot update
HI Tamas,
Thanks for the explanation:
MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) When moving is done just jumps to the reset handler of the new image.
1. What does "move" mean in this context. Write the image to the flash in slot-0 and for this to happen and would it need platform specific hardware knowledge/driver and write privileges to secure flash? 2. What about the MCUBoot image format and FWU SUIT CBOR/COSE format dependencies - I believe these are orthogonal, as MCUBoot blob is wrapped by the SUIT? 3. What about the rollback policy and which component enforces it - MCUBoot or the FWU ? 4. Image tools: MCUBoot vs. SUIT clarity would help?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Tuesday, May 25, 2021 7:56 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V
MCUBoot user API ========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image
BR, Tamas
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application | | Function call V 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
MCUBoot image size is around 60K and
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
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@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 spechttps://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 documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. 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 linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, 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/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto: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@infineon.commailto:Suresh.Marisetty@infineon.com
Hi Suresh,
SUIT is on the TODO list of MCUboot community for a while but AFAIK nobody working on actively. But will ask and come back with the answer.
Reference implementation of FreeRTOS and FWU API has not support SUIT, it relies on MCUboot custom manifest (TLV) format.
Design doc: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techni...
BR, Tamas
From: Suresh.Marisetty@infineon.com Suresh.Marisetty@infineon.com Sent: 2021. augusztus 20., péntek 16:39 To: Tamas Ban Tamas.Ban@arm.com; Andrew Thoelke Andrew.Thoelke@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Firmware update API - MCUboot update
Hi Tamas,
Wondering if anybody is driving supporting SUIT for MCUBoot/imgtools and a potential ETA?
Also, can somebody throw light on the FreeRTOS support that was announced for the FWU API and how the entire flow works top down from RTOS to the baremetal. Has this reference addressed the SUIT issue?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Tuesday, May 25, 2021 11:51 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
First of all, I recommend to check https://mcuboot.com/ where all MCUboot specific info is available (design, porting guide, supported crypto features, etc, ). Furthermore, there is a slack channel (link from previous website) to ask the community.
1.) "Moving" in this context (default build options) means to swap the images physically in between primary and secondary slot. So, old image goes to secondary slot and new image copied to primary slot. This makes possible reverting a faulty (valid, but non-functional) image and restore device operational status. However, there are many upgrade strategies (overwrite-only, direct-xip, ram-load, etc.) in which case images might not be moved at all, or old image is not preserved. Details in the design documentation. MCUboot relies on a flash driver which is platform dependent, a HAL is defined. MCUboot is executed in secure mode, so it can access to entire flash. The access demand of FWU partition depends on how the secondary slot is configured, it can be S or NS. It is an implementation choice.
2.) MCUboot currently supports only its own custom manifest format (header + metadata in TLV format attached to the image). SUIT support is planned. AFAIK they will be either header + TLV manifest or header + SUIT manifest.
3.) In the current design MCUboot enforce the rollback policy.
4.) Imgtool Python script is support the custom manifest format. I assume when SUIT manifest support will be added then imgtool also will support it.
BR, Tamas
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: 2021. május 25., kedd 17:44 To: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Firmware update API - MCUboot update
HI Tamas,
Thanks for the explanation:
MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) When moving is done just jumps to the reset handler of the new image.
1. What does "move" mean in this context. Write the image to the flash in slot-0 and for this to happen and would it need platform specific hardware knowledge/driver and write privileges to secure flash? 2. What about the MCUBoot image format and FWU SUIT CBOR/COSE format dependencies - I believe these are orthogonal, as MCUBoot blob is wrapped by the SUIT? 3. What about the rollback policy and which component enforces it - MCUBoot or the FWU ? 4. Image tools: MCUBoot vs. SUIT clarity would help?
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Tuesday, May 25, 2021 7:56 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
Hi Suresh,
I think still there is some misunderstanding here about the role of MCUboot in the update process.
I try to clarify it:
* MCUboot is the *bootloader* in the system, it does not care how the new images are getting installed on the device. * MCUboot defines a static allocation of the flash. There are the primary slot where the active runtime images are stored and executed from there (if upgrade startegy is XIP) and there are the secondary slot where the candidate image is written by the update client, which his part of the runtime firmware. * MCUboot is not involved at all in the process when new image is downloaded from the remote server and written to the flash (to secondary slot). * MCUboot jobs to recognize that there is a new image (magic value is set at the end of secondary slot), validates it (hash + signature) and move it (if valid) to the primary slot to make it executable (because image is XIP and linked to the address space of the primary slot) * When moving is done just jumps to the reset handler of the new image.
TF-M expose a standard FWU API, which can be used by any cloud client:
* FWU partition in the secure side is responsible to write the new image to the flash * Because TF-M relies on MCUBoot as a bootloader therefore the image must be placed to the right place in the flash (secondary slot) and some MCUboot specific flags must be set (magic value to indicate new image existence). Therefore in the FWU secure partition there is a MCUboot shim layer to handle these bootloader specific task * However, MCUBoot can replaced by any bootloader if one wants and then the shim layer also can be replaced to do other bootloader specific things. * In this architecture update client is responsible to download the image from the remote server and the FWU partition is responsible to write it to the right location.
An implementer can choose:
* Implement the FWU API on the non-secure side * Do not use FWU API, just writes the image to the right flash location and set certain flags in the flash that allows MCUboot to find the image * Replace MCUboot with custom bootloader if he wants
I hope this helps!
The call path in the previous mail was incorrect. The correct call path is:
Update client application | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot Shim Layer | | Function call V
MCUBoot user API ========================== RESTART ======================
MCUboot engine parse flash, validate new image, if there is any, and move it around to the primary slot | | V Function call, never returns Reset_Handler of new image
BR, Tamas
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 2021. május 25., kedd 16:16 To: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update
Hi Andrew,
I am thinking of two paths for the update client application: one through MCUBoot and another direct to the FWU interface. MCUBoot path is for legacy application compatibility purpose. Longer term, I am wondering if MCUBoot is needed.
In embedded there is always a challenge to optimize the code size as space in storage is limited and any optimization to remove redundancies will help.
Update client application | | Function call V 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
MCUBoot image size is around 60K and
thanks Suresh Marisetty Infineon Semiconductor Corporation
From: Andrew Thoelke <Andrew.Thoelke@arm.commailto:Andrew.Thoelke@arm.com> Sent: Tuesday, May 25, 2021 1:39 AM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://goto.infineon.com/SocialEngineering.
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@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 spechttps://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 documenthttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/technical_references/tfm_fwu_service.rst#n75. 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 linkhttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/partitions/firmware_update/bootloader/mcuboot/tfm_mcuboot_fwu.c#n298.
Can you please provide more specific suggestion or questions?
Regards, Sherry Zhang
From: Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2@arm.commailto:Sherry.Zhang2@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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@arm.commailto:Sherry.Zhang2@arm.com> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty@infineon.commailto:Suresh.Marisetty@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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 safehttps://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 OTAhttps://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractions/ota_pal_psa/README.md#what-is-this-project, 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/techni....
Regards, Sherry Zhang
From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto: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@lists.trustedfirmware.orgmailto: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@infineon.commailto:Suresh.Marisetty@infineon.com
tf-m@lists.trustedfirmware.org
-
Suresh.Marisetty＠infineon.com -
Tamas Ban