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

[AKASHI Takahiro]

On Thu, May 13, 2021 at 06:32:13PM +0200, Heinrich Schuchardt wrote:
> On 5/13/21 6:12 PM, Masami Hiramatsu wrote:
> > 2021年5月13日(木) 19:27 Ilias Apalodimas <ilias.apalodimas at linaro.org>:
> > > 
> > > On Thu, May 13, 2021 at 05:38:51PM +0900, AKASHI Takahiro wrote:
> > > > On Thu, May 13, 2021 at 05:18:36PM +0900, Masami Hiramatsu wrote:
> > > > > 2021年5月13日(木) 16:24 AKASHI Takahiro <takahiro.akashi at linaro.org>:
> > > > > 
> > > > > > > > > > BTW, IMHO, if u-boot.bin can not find the ESL in the device tree,
> > > > > > > > > > it should skip authentication too.
> > > > > > > > > 
> > > > > > > > > In this case the capsule should be rejected (if
> > > > > > > > > CONFIG_EFI_CAPSULE_AUTHENTICATE=y).
> > > > > > > > 
> > > > > > > > That's basically right.
> > > > > > > > But as I mentioned in my comment against Sughosh's patch,
> > > > > > > > the authentication process will be enforced only if the capsule has
> > > > > > > > an attribute, IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED.
> > > > > > > > 
> > > > > > > 
> > > > > > > That would be a security desaster.
> > > > > > 
> > > > > > The requirement that I mentioned above is clearly described
> > > > > > in UEFI specification.
> > > > > > If you think that it is a disaster, please discuss the topic
> > > > > > in UEFI Forum first.
> > > > > 
> > > > > I confirmed UEFI specification, version 2.7, Section.23.1
> > > > > the last of EFI_FIRMWARE_MANAGEMENT_PROTOCOL.GetImageInfo()
> > > > > 
> > > > > -----------------
> > > > > If IMAGE_ATTRIBUTE_AUTHENTICATION_REQUIRED is supported and clear, then
> > > > > authentication is not required to perform the firmware image operations.
> > > > > -----------------
> > > > 
> > > > Thank you for citing this.
> > > > 
> > > > > Oh, this is really crazy because deciding whether to authenticate the
> > > > > suspicious
> > > > > package or not, depends on whether the package said "please
> > > > > authenticate me" or not. :D
> > > > 
> > > > Well, the attributes can been fetched with GetInfo API, but
> > > > how it is managed depends on the implementation of FMP drivers.
> > > > 
> > > > As I proposed somewhere else, those attributes should be
> > > > maintained in a separate place (maybe as part of system's policy),
> > > > presumably ESRT or platform-specific internal database?
> > > 
> > > 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.
> 
> If you want to build tools only, you can do so with 'make tools'. The
> tools target must include mkeficapsule irrespective of configuration.

So far, we have been discussing whether CONFIG_EFI_CAPSULE_AUTHENTICATE
(or "host" version like CONFIG_HOST_EFI_CAPSULE_AUTHENITATE)
be honored in mkeficapsule.c or not.

> This line in tools/Makefile must be corrected:
> 
> -hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
> +hostprogs-y += mkeficapsule

There exist lots of "hostprogs-$(CONFIG_...)" targets.
I think that this is a common practice in U-Boot.

-Takahiro Akashi

> Best regards
> 
> Heinrich