[PATCH v5 0/4] FMP versioning support

[Masahisa Kojima]

Hi Akashi-san,

On Tue, 11 Apr 2023 at 10:48, Takahiro Akashi
<takahiro.akashi at linaro.org> wrote:
>
> 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)?

Yes, there is a problem that we need to maintain the fw_version
in both FMP Payload Header and dtb, it is not an ideal situation and
prone to errors.

On second thought, I need to change my approach again.
fw_version: specified in FMP Payload Header and stored in EFI variable
lowest_supported_version: stored in dtb

When the capsule update is performed, U-Boot gets the fw_version from
FMP Payload Header
of the ongoing capsule, then checks if the version is equal to or
greater than lowest_supported_version
read from dtb.
One disadvantage is that fw_version in the EFI variable can be tampered
if the backing storage is file, but it is not the critical issue.

Thanks,
Masahisa Kojima

>
> 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
> >