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

[Simon Glass]

Hi Sughosh,

On Fri, 9 Apr 2021 at 23:27, Sughosh Ganu <sughosh.ganu at linaro.org> wrote:
>
> 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.

I wonder why another method would be needed, but if it, then someone
can turn your thing into a choice, I suppose.

Regards,
Simon