[PATCH v6 0/8] FMP versioning support
Masahisa Kojima
masahisa.kojima at linaro.org
Mon May 22 06:32:48 CEST 2023
On Fri, 19 May 2023 at 19:32, Masahisa Kojima
<masahisa.kojima at linaro.org> wrote:
>
> Firmware version management is not implemented in the current
> FMP implementation. This series aims to add the versioning support
> in FMP.
>
> 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.
>
> EDK II reference implementation utilizes the FMP Payload Header
> inserted right before the capsule payload.
> U-Boot also follows the EDK II implementation.
> 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.
>
> There is a design consideration for lowest supported version.
> 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 lowest supported version in the device tree.
> We can trust the information from dtb as long as the former
> stage boot loader verifies the image containing the dtb.
> The firmware version can not be stored in device tree because
> not all the capsule files do not have a device tree.
>
> 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 v6:
> - change the location of fw_version and lowest supported version
> - fw_version is stored in FMP Payload Header in the capsule file
> - lowest_supported_version is stored in the device tree
I forgot to notice that this series does not include python tests.
After we agree on the design, python tests will follow.
- fw_version is in FMP Payload Header of the capsule file
- lowest-supported-version is in the dtb
Thanks,
Masahisa Kojima
>
> 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_MULT
>
> Masahisa Kojima (8):
> efi_loader: add the number of image entries in efi_capsule_update_info
> efi_loader: store firmware version into FmpState variable
> efi_loader: versioning support in GetImageInfo
> efi_loader: get lowest supported version from device tree
> efi_loader: check lowest supported version
> mkeficapsule: add FMP Payload Header
> doc: uefi: add firmware versioning documentation
> doc: uefi: add anti-rollback documentation
>
> arch/arm/mach-rockchip/board.c | 4 +-
> .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 2 +-
> .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 2 +-
> board/emulation/qemu-arm/qemu-arm.c | 2 +-
> board/kontron/pitx_imx8m/pitx_imx8m.c | 2 +-
> board/kontron/sl-mx8mm/sl-mx8mm.c | 2 +-
> board/kontron/sl28/sl28.c | 2 +-
> board/rockchip/evb_rk3399/evb-rk3399.c | 2 +-
> board/sandbox/sandbox.c | 2 +-
> board/socionext/developerbox/developerbox.c | 2 +-
> board/st/stm32mp1/stm32mp1.c | 2 +-
> board/xilinx/common/board.c | 2 +-
> doc/develop/uefi/uefi.rst | 61 ++++
> .../firmware/firmware-version.txt | 22 ++
> doc/mkeficapsule.1 | 10 +
> include/efi_loader.h | 3 +-
> lib/efi_loader/efi_firmware.c | 273 ++++++++++++++++--
> lib/fwu_updates/fwu.c | 2 +-
> tools/eficapsule.h | 30 ++
> tools/mkeficapsule.c | 37 ++-
> 20 files changed, 421 insertions(+), 43 deletions(-)
> create mode 100644 doc/device-tree-bindings/firmware/firmware-version.txt
>
> --
> 2.17.1
>
More information about the U-Boot
mailing list