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

[Simon Glass <sjg@chromium.org>]

Hi Ilias,

On Sat, 17 Jul 2021 at 01:24, Ilias Apalodimas
<ilias.apalodimas@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@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@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.

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

Regards,
Simon