| Message ID | 20230519103214.1239656-1-masahisa.kojima@linaro.org |
|---|---|
| Headers | show |
| Series | FMP versioning support | expand |
On Fri, 19 May 2023 at 19:32, Masahisa Kojima <masahisa.kojima@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 >
On 5/19/23 12:32, Masahisa Kojima 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 > > 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 > Why are there no changes in directory test/ ? Could you add a test for the rollback protection? Best regards Heinrich
On Sun, 28 May 2023 at 17:54, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 5/19/23 12:32, Masahisa Kojima 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 > > > > 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 > > > > Why are there no changes in directory test/ ? > Could you add a test for the rollback protection? Yes, I will include the test in the next version. Thanks, Masahisa Kojima > > Best regards > > Heinrich