[PATCH 1/4] tools: mkeficapsule: add firmwware image signing

[AKASHI Takahiro]

On Thu, May 13, 2021 at 07:42:04PM +0300, Ilias Apalodimas wrote:
> [...]
> > > > FWIW I personally don't think we should even have a config option. But even
> > > > if we did it certainly must not be dictated by a hardware config.
> > > > 
> > > > When you install distro packages you accept whatever dependencies the
> > > > package has. mkeficapsule is a capsule creation and signing tool.  I don't
> > > > see any reason for keeping the creation and signing apart.
> > > 
> > > My question is, since the U-Boot binary is heavily dependent on the target
> > > platform, can we split the u-boot.bin creation (may include embedding keys)
> > > and the capsule file creation (including signing)?
> > 
> > Building U-Boot and creating a capsule are totally separate. Maybe you
> > get the first capsule years after you buy your board. But this should
> > not stop us from building mkeficapsule when building U-Boot.
> > 
> 
> Based on what was discussed in the thread waht I think would make more
> sense is:
> - Build u-boot and use the script Akashi sent to inject the certificate. 
>   Whether we create a single binary (always signed if a config option is
>   there) or 2 binaries (1 signed. 1 unsigned) is an implemetation detail
>   and I am fine with either.

Let me make clear: "a single binary or 2 binaries" is not
an implementation detail, but it's a matter of user's (, distro's
or whoever wants to provide a capsule) policy.

> - Use mkefi capsule to create the final capsule

If signing feature is enabled in mkeficapsule, you can create
both a signed capsule and an unsigned capsule.
And yet, some users may totally had no need to authentication
for firmware update using UEFI interfaces on their systems.
For them, signing should be able to be disabled.

> 
> > If you want to build tools only, you can do so with 'make tools'. The
> > tools target must include mkeficapsule irrespective of configuration.
> > 
> > This line in tools/Makefile must be corrected:
> > 
> > -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> > +hostprogs-y += mkeficapsule
> 
> So that's the point exactly. Building the tool is completely disjoint from
> building a u-boot binary.   Also you usually start adding config options to
> an app, when it starts getting to big and you want discrete functionality. 

I don't get your point.
As far as we maintain CONFIG_(HOST_)_EFI_CAPSULE_AUTHENTICATE,
we can and should guarantee the compatibility.

> I don't see any reason for making a simple tool, which is supposed to do 2
> things (create/sign), require config options and more over config options
> *for U-Boot*.

I don't get you point neither.

> I also think it's extremely unlikely to get any working distro 
> without libssl. 

Again, (major) distros are ones of users.
There may be bunch of users who may build/maintain their systems
on their way and not expect any authentication.

Having said that,
coincidentally there is happening a similar discussion
about building host tools and host-specific configs among Simon, Tom
and Alex[1].
(The background for the discussion is a bit different though.)

I'd like to see and follow the direction to be agreed there.

[1] https://lists.denx.de/pipermail/u-boot/2021-May/449050.html

-Takahiro Akashi

> > 
> > Best regards
> > 
> > Heinrich