[RFC 00/14] efi_loader: add capsule update support
takahiro.akashi at linaro.org
Wed Mar 18 03:04:05 CET 2020
Thank you for your quick review.
On Tue, Mar 17, 2020 at 08:49:12AM +0100, Heinrich Schuchardt wrote:
> On 3/17/20 3:12 AM, AKASHI Takahiro wrote:
> > Summary
> > =======
> > 'UpdateCapsule' is one of runtime services defined in UEFI specification
> > and its aim is to allow a caller to pass information to the firmware.
> > This is mostly used to update firmware binary on devices by instructions
> > from OS.
> > In this patch series, all the related definitions and structures are given
> > as UEFI specification describes and basic framework for capsule support is
> > implemented. Currently supported types of capsule are
> > * firmware update (Firmware Management Protocol or simply FMP)
> > * variable update
> > UpdateCapsule is a runtime services function, but is, at least initially,
> > provided only before exiting boot services alike other runtime functions.
> > This is because modifying storage which may be shared with OS must be
> > carefully designed and there is no general assumption to do that as in
> > the case of [Get/]SetVariable.
> > Instead, any capsule can be handed over to the firmware as a file on
> > a specific file system. In other words, we only support "capsules on disk"
> > for now.
> > Regarding firmware update, most of functionality is provided by FMP
> > driver and it will be by nature system/platform-specific. So you can and
> > should implement FMP drivers based on your system requirements.
> > In this patch series, only a simple FMP driver based on FIT image for
> > a single region is supported. (So it is "for reference only")
> > See more details in "efi_loader: capsule: add simple firmware management
> > protocol."
> > Regarding variable update, the implementation here is based on a draft
> > proposal by Peter in Boot-arch ML. The specification should be discussed
> > and finalized first. So the code doesn't fully implement Peter's idea.
> >  https://lists.linaro.org/pipermail/boot-architecture/2018-October/000883.html
> I do not like the idea of exposing variables as a configuration table as
> operating system users may start doing strange things like accessing
> variables via the configuration table. Why not keep the pointer to the
> internal storage of variable hidden in your runtime code and expose the
> runtime services defined in the UEFI spec?
> Please, elaborate on the benefit of your approach.
I have already commented on your reply to my patch#11.
Rather, my aim of this patch is to discuss the following points:
> > Issues
> > ======
> > * Timing of executing capsules-on-disk
> > Currently, processing a capsule is triggered only as part of
> > UEFI subsystem initialization. This means that, for example,
> > firmware update, may not take place at system booting time and
> > will potentially be delayed until a first call of any UEFI functions.
> > TODO's
> > ======
> > (May or may not be addressed in future versions of this series.)
> > * capsule authentication
> > * capsule dependency (dependency expression instruction set)
> > * loading drivers in a capsule
> > * handling RESET flag in a capsule and QeuryCapsuleCaps
> > * full semantics of ESRT (EFI System Resource Table)
> > * enabling capsule API at runtime
> > * json capsule
> > * recovery from update failure
What functionality should be initially included in my first implementation
for capsule support.
FYI, Sughosh is going to work on
* capsule authentication
* recovery from update failure (or at least, A/B partition)
in the coming months.
> > Changes
> > =======
> > Initial release as RFC (March 17, 2020)
> > AKASHI Takahiro (14):
> > efi_loader: define OsIndicationsSupported flags
> > efi_loader: define System Resource Table macros
> > efi_loader: export a couple of protocol related functions
> > efi_loader: correct a definition of struct efi_capsule_header
> > efi_loader: define UpdateCapsule api
> > efi_loader: capsule: add capsule_on_disk support
> > efi_loader: capsule: add memory range capsule definitions
> > efi_loader: capsule: support firmware update
> > efi_loader: add simple firmware management protocol for FIT image
> > efi_loader: capsule: support variable update
> > efi_loader: variable: export variables table for runtime access
> > cmd: add "efidebug capsule" command
> > tools: add mkeficapsule command for UEFI capsule update test
> > test/py: add efi capsule test
> > cmd/efidebug.c | 234 +++++
> > include/efi_api.h | 214 ++++-
> > include/efi_loader.h | 53 ++
> > lib/efi_loader/Kconfig | 65 ++
> > lib/efi_loader/Makefile | 2 +
> > lib/efi_loader/efi_boottime.c | 29 +-
> > lib/efi_loader/efi_capsule.c | 860 ++++++++++++++++++
> > lib/efi_loader/efi_firmware.c | 191 ++++
> > lib/efi_loader/efi_runtime.c | 104 ++-
> > lib/efi_loader/efi_setup.c | 41 +-
> > lib/efi_loader/efi_variable.c | 109 +++
> > test/py/tests/test_efi_capsule/conftest.py | 109 +++
> > test/py/tests/test_efi_capsule/defs.py | 21 +
> > .../test_efi_capsule/test_capsule_firmware.py | 102 +++
> > .../test_efi_capsule/test_capsule_variable.py | 141 +++
> > test/py/tests/test_efi_capsule/uboot_env.its | 25 +
> > tools/Makefile | 3 +
> > tools/mkeficapsule.c | 501 ++++++++++
> > 18 files changed, 2744 insertions(+), 60 deletions(-)
> > create mode 100644 lib/efi_loader/efi_capsule.c
> > create mode 100644 lib/efi_loader/efi_firmware.c
> > create mode 100644 test/py/tests/test_efi_capsule/conftest.py
> > create mode 100644 test/py/tests/test_efi_capsule/defs.py
> > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware.py
> > create mode 100644 test/py/tests/test_efi_capsule/test_capsule_variable.py
> > create mode 100644 test/py/tests/test_efi_capsule/uboot_env.its
> > create mode 100644 tools/mkeficapsule.c
More information about the U-Boot