Re: [PATCH v5 0/4] FMP versioning support

[Takahiro Akashi <takahiro.akashi@linaro.org>]

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
>