[PATCH v5 0/4] FMP versioning support
Takahiro Akashi
takahiro.akashi at linaro.org
Tue Apr 11 03:48:15 CEST 2023
Hi Kojima-san,
On Mon, Apr 10, 2023 at 06:07:28PM +0900, Masahisa Kojima wrote:
> Firmware version management is not implemented in the current
> FMP implementation. This series aims to add the versioning support
> in FMP.
>
> There is a major design change in v5.
> Until v4, the fw_version and lowest_supported_version are stored
> as a EFI variable. If the backing storage is a file we can't trust
> any of that information since anyone can tamper with the file,
> although the variables are defined as RO.
> With that, we store the version information in the device tree
> in v5. We can trust the information from dtb as long as the former
> stage boot loader verifies the image containing the dtb.
I have a basic question here.
You said that the former-stage boot loader is responsible for maintaining
the dtb with the correct firmware version to be passed to U-Boot.
But how can it obtain the new version number of firmware which is only
contained in a capsule file (and its header)?
Looking into you pytest, you simply always *reboot* the sandbox with
an already-modified dtb (test_ver.dtb).
(Please note that, at the reboot time, a capsule has not been
applied yet.)
I believe that your current approach is rather incomplete
as a workable solution.
-Takahiro Akashi
> The disadvantage of this design change is that we need to maintain
> the fw_version in both device tree and FMP Payload Header.
> It is inevitable since not all the capsule files contain the dtb.
>
> EDK II reference implementation utilizes the FMP Payload Header
> inserted right before the capsule payload. With this series,
> U-Boot also follows the EDK II implementation.
>
> Currently, there is no way to know the current running firmware
> version through the EFI interface. FMP->GetImageInfo() returns
> always 0 for the version number. So a user can not know that
> expected firmware is running after the capsule update.
>
> With this series applied, version number can be specified
> in the capsule file generation with mkeficapsule tool, then
> user can know the running firmware version through
> FMP->GetImageInfo() and ESRT.
>
> Note that this series does not mandate the FMP Payload Header,
> compatible with boards that are already using the existing
> U-Boot FMP implementation.
> If no FMP Payload Header is found in the capsule file, fw_version,
> lowest supported version, last attempt version and last attempt
> status is set to 0 and this is the same behavior as existing FMP
> implementation.
>
> Major Changes in v5:
> - major design changes, versioning is implemented with
> device tree instead of EFI variable
>
> Major Changes in v4:
> - add python-based test
>
> Major Changes in v3:
> - exclude CONFIG_FWU_MULTI
>
> Masahisa Kojima (4):
> efi_loader: get version information from device tree
> efi_loader: check lowest supported version
> mkeficapsule: add FMP Payload Header
> test/py: efi_capsule: test for FMP versioning
>
> .../firmware/firmware-version.txt | 25 +++
> doc/mkeficapsule.1 | 10 +
> lib/efi_loader/efi_firmware.c | 187 +++++++++++++---
> test/py/tests/test_efi_capsule/conftest.py | 73 +++++++
> .../test_capsule_firmware_fit.py | 187 ++++++++++++++++
> .../test_capsule_firmware_raw.py | 201 ++++++++++++++++++
> .../test_capsule_firmware_signed_fit.py | 165 ++++++++++++++
> .../test_capsule_firmware_signed_raw.py | 169 +++++++++++++++
> test/py/tests/test_efi_capsule/version.dts | 27 +++
> tools/eficapsule.h | 30 +++
> tools/mkeficapsule.c | 37 +++-
> 11 files changed, 1082 insertions(+), 29 deletions(-)
> create mode 100644 doc/device-tree-bindings/firmware/firmware-version.txt
> create mode 100644 test/py/tests/test_efi_capsule/version.dts
>
> --
> 2.17.1
>
More information about the U-Boot
mailing list