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