[PATCH 2/3] mkeficapsule: Remove dtb related options

[Ilias Apalodimas]

On Tue, 20 Jul 2021 at 21:33, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Ilias,
>
> On Sat, 17 Jul 2021 at 01:24, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > On Fri, Jul 16, 2021 at 08:03:23AM -0600, Simon Glass wrote:
> > > Hi Ilias,
> > >
> > > On Thu, 15 Jul 2021 at 11:00, Ilias Apalodimas
> > > <ilias.apalodimas at linaro.org> wrote:
> > > >
> > > > commit 322c813f4bec ("mkeficapsule: Add support for embedding public key in a dtb")
> > > > added a bunch of options enabling the addition of the capsule public key
> > > > in a dtb.  Since now we embeded the key in U-Boot's .rodata we don't this
> > > > this functionality anymore
> > > >
> > > > Signed-off-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>
> > > > ---
> > > >  tools/mkeficapsule.c | 226 ++-----------------------------------------
> > > >  1 file changed, 7 insertions(+), 219 deletions(-)
> > >
> > > Here again I see EFI diverging from the impl in U-Boot. WIth U-Boot
> > > you can add the public key after the build step, e.g. in a key-signing
> > > server. With EFI and this change you will have to rebuild U-Boot (from
> > > source) every time you sign something. Seems like a pain.
> >
> > I don't see why either of this is a problem.  You need the public key to
> > update the binary it self, so rebuilding from source is a prerequisite.
>
> Please can you have a look at binman and the concept of packaging
> separate from building? Rebuilding from source is definitely not
> needed to update a binary.

Sure I'll take a look. We already have an mkeficapsule.c though, which
in theory could take care of the capsule signing.  The point is that
we don't uses that key to sign anything, we use it to authenticate the
capsule that tries to update the firmware.

>
> >
> > Apart from a signing server, you can also have special hardware that provides
> > the public key you need (which is not implemented yet).  So this is the bare
> > minimum functionality you need  for authenticated capsule updates.
>
> As discussed on the mailing list you have not included the motivation
> for this.

To be fair, I did on patch 1/3.

> Now that I understand the motivation, which is to avoid
> someone changing the key at runtime, I believe that this change does
> not actually help...I've replied separately on the mailing list.

It does help, but you need combined code which doesn't exist in either
case.  Anyway, I'll reply on the other thread

Cheers
/Ilias
>
> Regards,
> Simon