Hi Patryk

The short answer is that the PSA-A FWU SW architecture is platform specific. It largely depends on what flash(es) are available in the system. For systems with a single eMMC system flash (e.g. most embedded/mobile systems), it's common to have the Update Agent implemented in the REE, since the REE owns access to the eMMC and all firmware must be stored there. In that case there is no need to implement the SMC ABIs in FWU-A, although other parts of the specification (e.g. the FWU metadata format) are still relevant.

In other systems (e.g. server or specialist embedded), there may be a dedicated flash for secure firmware. In that case, the FWU-A ABIs may be implemented. That is preferable from a security point of view but has additional cost.

I'll let someone else comment on the status of the Trusted Services FWU-A implementation and what platforms it's used in.

Regards

Dan.

-----Original Message----- From: Patryk via Trusted-services <trusted- services@lists.trustedfirmware.org> Sent: Thursday, August 29, 2024 2:55 PM To: trusted-services@lists.trustedfirmware.org Subject: [Trusted-services] Questions Regarding PSA Firmware Update and Trusted Firmware Services

Hey, I have some issues understanding a few things related to https://www.trustedfirmware.org/, specifically:

https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware- update.html PSA Firmware Update (PSA FWU)

https://trusted-services.readthedocs.io/en/latest/services/fwu/index.html Firmware Update Service

I’ve asked on other mailing lists, but unfortunately, no one responded.

I’m writing this in the context of ARMv8 architecture machines, where (roughly) we have the following stack running:

• payload understandable by the vendor's bootROM
• TF-A BL2
• TF-A BL31 as EL3 runtime services
• OP-TEE as BL32
• u-boot as BL33
• Linux

I will refer to BL31 and BL32 as firmware.

In the PSA Firmware Update specification, the entire procedure is described, outlining how it should work, e.g., the update process is initiated by the Update Client running in REE (e.g., some process on Linux), and it describes how metadata should be handled, rollback, etc.

Assuming that my storage is eMMC, where all these things are stored, divided into partitions (let's skip offsets and other details):

• bootROM payload
• bl2
• fip-a (required by bl2 with PSAFWUSUPPORT)
• fip-b (required by bl2 with PSAFWUSUPPORT)
• metadata-a (required by bl2 with PSAFWUSUPPORT)
• metadata-b (required by bl2 with PSAFWUSUPPORT)
• boot (e.g., with fitimage)
• rootfs-a
• rootfs-b
• data

As I was reviewing the specification, it seemed that the firmware update should be conducted in the secure world, which (in my opinion) would mean that, for example, fip-x and metadata-x are updated somehow from the secure world, let’s say by a TA running in OP-TEE. However:

• OP-TEE doesn't have drivers for eMMC (simply put - for example, to

store data securely, OP-TEE communicates with Linux to write data to eMMC).

• When I started googling and asking around (e.g., on Reddit), people

told me that it's not the case at all, and typically some process runs on Linux, like RAUC or SWUPDATE, and it just writes whatever is needed to fip-x and metadata-x - so the whole update takes place in the so-called REE.

And now my question is - I assume that this specification and trusted services (particularly the FWU service) that I linked were designed for a reason - so my question is, what is the use case? Could this be more applicable to "small MCUs" rather than microprocessors (even though the specification I linked concerns Cortex-A)? Or is this used on servers? Perhaps the nature of embedded systems is such that we don't use it and just take RAUC or some other SWUPDATE and write what is needed, and the fact that the system is trustworthy is ensured by the chain-of-trust?

Best regard

Patryk

Trusted-services mailing list -- trusted-services@lists.trustedfirmware.org To unsubscribe send an email to trusted-services- leave@lists.trustedfirmware.org

Hi Patryk,

“As I was reviewing the specification, it seemed that the firmware update should be conducted in the secure world,” IMHO the specification does not state this. If we look at the big picture, some components participating in the overall FWU flow will always execute in the SWd (e.g. BL1/2). The FWU agent in turn could execute in the NWd (in the linux user-space as service, in a dedicated VM, in the Linux kernel, in the bootloader (e.g. u-boot), etc…). Where it shall run depends on the use-case and on the capabilities of the HW platform.

“Assuming that my storage is eMMC” In this case the eMMC driver executes in the NWd (the boot-loader or in the Linux kernel or hypervisor depending on the boot stage and design of the device). The eMMC device cannot have multiple concurrent users and locking is needed. It would be rather challenging to implement resource management between the SWd and NWd components and AFAIK this is never implemented . The eMMC device is owned by the NWd and no SWd component has direct access to it. If SWd components need access (e.g. in case of RPMB), then the NWd has to implement a provider and the SWd will turn to it for services (in case of RPMB read/write requests).

“I assume that this specification and trusted services (particularly the FWU service) that I linked were designed for a reason” The specification aims to standardize firmware update on arm devices. The idea is to provide a common interface and workflow to clients. E.g. if RAU of SWUPDATE would implement an FWU client, it could become platform independent. Although it would need to be able to select the right communication driver based on the platform, most of the FWU process would be the same independent of where the FWU agent is deployed. The FWU Agent running as a Trusted Service is a viable solution on platforms where the firmware storage device can only be accessed from the SWd. On such devices the TS FWU SP executing at S-EL0 can be a solution to allow updating the content of this device.

Hope this helps, feel free to come back if you have further questions or any comments.

/George

From: Patryk via Trusted-services trusted-services@lists.trustedfirmware.org Date: Thursday, 29 August 2024 at 16:05 To: trusted-services@lists.trustedfirmware.org trusted-services@lists.trustedfirmware.org Subject: [Trusted-services] Questions Regarding PSA Firmware Update and Trusted Firmware Services Hey, I have some issues understanding a few things related to https://www.trustedfirmware.org/, specifically:

- https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-updat... PSA Firmware Update (PSA FWU) - https://trusted-services.readthedocs.io/en/latest/services/fwu/index.html Firmware Update Service

I’ve asked on other mailing lists, but unfortunately, no one responded.

I’m writing this in the context of ARMv8 architecture machines, where (roughly) we have the following stack running:

- payload understandable by the vendor's bootROM - TF-A BL2 - TF-A BL31 as EL3 runtime services - OP-TEE as BL32 - u-boot as BL33 - Linux

I will refer to BL31 and BL32 as firmware.

In the PSA Firmware Update specification, the entire procedure is described, outlining how it should work, e.g., the update process is initiated by the Update Client running in REE (e.g., some process on Linux), and it describes how metadata should be handled, rollback, etc.

Assuming that my storage is eMMC, where all these things are stored, divided into partitions (let's skip offsets and other details):

- bootROM payload - bl2 - fip-a (required by bl2 with PSAFWUSUPPORT) - fip-b (required by bl2 with PSAFWUSUPPORT) - metadata-a (required by bl2 with PSAFWUSUPPORT) - metadata-b (required by bl2 with PSAFWUSUPPORT) - boot (e.g., with fitimage) - rootfs-a - rootfs-b - data

As I was reviewing the specification, it seemed that the firmware update should be conducted in the secure world, which (in my opinion) would mean that, for example, fip-x and metadata-x are updated somehow from the secure world, let’s say by a TA running in OP-TEE. However:

- OP-TEE doesn't have drivers for eMMC (simply put - for example, to store data securely, OP-TEE communicates with Linux to write data to eMMC). - When I started googling and asking around (e.g., on Reddit), people told me that it's not the case at all, and typically some process runs on Linux, like RAUC or SWUPDATE, and it just writes whatever is needed to fip-x and metadata-x - so the whole update takes place in the so-called REE.

And now my question is - I assume that this specification and trusted services (particularly the FWU service) that I linked were designed for a reason - so my question is, what is the use case? Could this be more applicable to "small MCUs" rather than microprocessors (even though the specification I linked concerns Cortex-A)? Or is this used on servers? Perhaps the nature of embedded systems is such that we don't use it and just take RAUC or some other SWUPDATE and write what is needed, and the fact that the system is trustworthy is ensured by the chain-of-trust?

Best regard

Patryk -- Trusted-services mailing list -- trusted-services@lists.trustedfirmware.org To unsubscribe send an email to trusted-services-leave@lists.trustedfirmware.org