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

[AKASHI Takahiro]

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