[RFC 00/14] efi_loader: add capsule update support

AKASHI Takahiro
2020-03-31T04:36:19Z

Heinrich,

On Wed, Mar 18, 2020 at 11:04:05AM +0900, AKASHI Takahiro wrote:
> Heinrich,
>
> 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[1] by Peter in Boot-arch ML. The specification should be discussed
> > > and finalized first. So the code doesn't fully implement Peter's idea.
> > >
> > > [1] 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:

Do you have any comments on them?

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

We, Linaro, internally discussed this issue and agreed that the current
capsule handling should be split from UEFI initialization code,
efi_init_obj_list(), and that both of them should be called respectively
as early as possible in U-Boot initialization time, probably in board_init_r().

We may restrict this behavior only if CAPSULE is enabled.

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

Do you have any primary requirements so that you will be happy to
accept my patch series?

-Takahiro Akashi

> FYI, Sughosh is going to work on
> * capsule authentication
> * recovery from update failure (or at least, A/B partition)
> in the coming months.
>
> Thanks,
> -Takahiro Akashi
>
>
>
> > >
> > >
> > > 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
> > >
> >