| Message ID | 20230410090732.1676-1-masahisa.kojima@linaro.org |
|---|---|
| Headers | show |
| Series | FMP versioning support | expand |
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 >
Hi Akashi-san, On Tue, 11 Apr 2023 at 10:48, Takahiro Akashi <takahiro.akashi@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 > >