[PATCH 0/5] Add support for embedding public key in platform's dtb

[Sughosh Ganu]

hi Simon,

On Fri, 9 Apr 2021 at 05:26, Simon Glass <sjg at chromium.org> wrote:

> Hi Sughosh,
>
> On Thu, 8 Apr 2021 at 18:53, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
> >
> > hi Simon,
> >
> > On Wed, 7 Apr 2021 at 21:44, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, 7 Apr 2021 at 23:54, Sughosh Ganu <sughosh.ganu at linaro.org>
> wrote:
> >> >
> >> > Patch 1 fixes an issue of selection of IMAGE_SIGN_INFO config option
> >> > when capsule authentication is enabled.
> >> >
> >> > Patch 2 add two config symbols, EFI_PKEY_DTB_EMBED and EFI_PKEY_FILE
> >> > which are used for enabling embedding of the public key in the dtb,
> >> > and specifying the esl file name.
> >> >
> >> > Patch 3 moves efi_capsule_auth_enabled as a weak function, which can
> >> > be used as a default mechanism for checking if capsule authentication
> >> > has been enabled.
> >> >
> >> > Patch 4 adds a default weak function for retrieving the public key
> >> > from the platform's dtb.
> >> >
> >> > Patch 5 adds the functionality to embed the esl file into the
> >> > platform's dtb during the platform build.
> >> >
> >> > I have tested this functionality on the STM32MP157C DK2 board.
> >> >
> >> > [1] - https://lists.denx.de/pipermail/u-boot/2021-March/442867.html
> >> >
> >> > Sughosh Ganu (5):
> >> >   efi_loader: Kconfig: Select IMAGE_SIGN_INFO when capsule
> >> >     authentication is enabled
> >> >   efi_loader: Kconfig: Add symbols for embedding the public key into
> the
> >> >     platform's dtb
> >> >   efi_capsule: Add a weak function to check whether capsule
> >> >     authentication is enabled
> >> >   efi_capsule: Add a weak function to get the public key needed for
> >> >     capsule authentication
> >> >   Makefile: Add provision for embedding public key in platform's dtb
> >> >
> >> >  Makefile                              | 10 ++++++
> >> >  board/emulation/common/qemu_capsule.c |  6 ----
> >> >  lib/efi_loader/Kconfig                | 16 ++++++++++
> >> >  lib/efi_loader/efi_capsule.c          | 44
> ++++++++++++++++++++++++---
> >> >  4 files changed, 66 insertions(+), 10 deletions(-)
> >> >
> >> > --
> >> > 2.17.1
> >> >
> >>
> >> We need to rethink the use of weak functions for this sort of thing,
> >> or we will end up with an unnavigable mess at some point. If we need
> >> to adjust the flow of boot, let's adjust the flow rather than adding
> >> hooks everywhere.
> >
> >
> > There are two weak functions being added. One is for retrieving the
> public key to be used for the capsule authentication, and the other is for
> checking for whether capsule authentication has been enabled. The reason
> why a weak function is needed is because platforms can have other
> mechanisms for retrieval of the public key or for testing if capsule
> authentication has been enabled.
> >
> > If we consider the case of public key retrieval, the majority of
> platforms would be built with the device tree concatenated with the u-boot
> binary. The weak function would cater to all of those platforms -- having a
> weak function would mean that we are not required to repeat the same
> functionality for every platform that uses the same mechanism for
> extracting the public key. However, there would be platforms where the
> public key is obtained through a different mechanism which is platform
> specific. Those platforms would have to define their own function to get
> the public key. Same for checking whether capsule authentication feature
> has been enabled or not.
> >
> > -sughosh
>
> Yes, I get it, but if this is to be a critical feature and part of the
> grand new design for verified boot using UEFI, surely we should be
> building a new front door, not digging a tunnel in the bathroom :-)
>
> We can either use drivers with driver model, or perhaps have a Kconfig
> that enables calling the function (so we get a link error if not
> provided). Or if there will be more than one handler, a linker_list.
>

I will use the Kconfig symbol for selecting the function to use for
retrieving the public key. So, in the current scenario, the function would
be under the CONFIG_EFI_PKEY_DTB_EMBED symbol. This should cater to the
majority of the cases. If some platform wants to use a different method to
get the public key, it would need to define it's own function.

-sughosh


>
> Perhaps it is time to consider a 'hook' system, with a command to let
> us see what hooks are active for any particular event?
>
> Regards,
> Simon
>