public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH 1/4] tools: mkeficapsule: add firmwware image signing
Date: Fri, 14 May 2021 13:50:31 +0900	[thread overview]
Message-ID: <20210514045031.GC15502@laputa> (raw)
In-Reply-To: <YJ1W3AnBeRHl4o7G@apalos.home>

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

  reply	other threads:[~2021-05-14  4:50 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12  4:57 [PATCH 0/4] efi_loader: capsule: improve capsule authentication support AKASHI Takahiro
2021-05-12  4:57 ` [PATCH 1/4] tools: mkeficapsule: add firmwware image signing AKASHI Takahiro
2021-05-12  8:56   ` Heinrich Schuchardt
2021-05-13  3:08     ` AKASHI Takahiro
2021-05-13  4:22       ` Heinrich Schuchardt
2021-05-13  5:00         ` AKASHI Takahiro
2021-05-13  5:35           ` Heinrich Schuchardt
2021-05-13  6:36             ` AKASHI Takahiro
2021-05-13  6:45               ` Heinrich Schuchardt
2021-05-13  7:45                 ` AKASHI Takahiro
2021-05-13  5:12         ` Masami Hiramatsu
2021-05-13  5:50           ` Heinrich Schuchardt
2021-05-13  6:44             ` Masami Hiramatsu
2021-05-13  6:52               ` Heinrich Schuchardt
2021-05-13  7:38                 ` AKASHI Takahiro
2021-05-13  6:50             ` AKASHI Takahiro
2021-05-13  6:55               ` Heinrich Schuchardt
2021-05-13  7:23                 ` AKASHI Takahiro
2021-05-13  8:18                   ` Masami Hiramatsu
2021-05-13  8:38                     ` AKASHI Takahiro
2021-05-13 10:27                       ` Ilias Apalodimas
2021-05-13 16:12                         ` Masami Hiramatsu
2021-05-13 16:32                           ` Heinrich Schuchardt
2021-05-13 16:42                             ` Ilias Apalodimas
2021-05-14  4:50                               ` AKASHI Takahiro [this message]
2021-05-14  7:56                                 ` Ilias Apalodimas
2021-05-14  4:13                             ` AKASHI Takahiro
2021-05-13 10:40                       ` Heinrich Schuchardt
2021-05-13 18:25                     ` Heinrich Schuchardt
2021-05-14  6:19                       ` AKASHI Takahiro
2021-05-14  6:59                         ` Heinrich Schuchardt
2021-05-14  7:13                           ` AKASHI Takahiro
2021-05-14  8:45                             ` Heinrich Schuchardt
2021-05-14  9:51                               ` AKASHI Takahiro
2021-05-14 10:08                                 ` Heinrich Schuchardt
2021-05-14 13:09                                 ` Masami Hiramatsu
2021-05-14 13:39                                   ` Ilias Apalodimas
2021-05-15  2:03                                   ` Heinrich Schuchardt
2021-05-15  2:14                                     ` Masami Hiramatsu
2021-05-12  4:57 ` [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation AKASHI Takahiro
2021-05-12  7:20   ` Ilias Apalodimas
2021-05-12  7:49     ` Masami Hiramatsu
2021-05-12  8:01       ` Ilias Apalodimas
2021-05-12 10:01         ` Heinrich Schuchardt
2021-05-13  2:33           ` AKASHI Takahiro
2021-05-13  5:08             ` Heinrich Schuchardt
2021-05-13  7:13               ` AKASHI Takahiro
2021-05-13 17:42                 ` Heinrich Schuchardt
2021-05-14  2:21                   ` [PATCH 2/4] tools: mkeficapsule: remove device-tree related operationy AKASHI Takahiro
2021-05-14  2:23                   ` [PATCH 2/4] tools: mkeficapsule: remove device-tree related operation Masami Hiramatsu
2021-05-12  4:57 ` [PATCH 3/4] tools: add fdtsig command AKASHI Takahiro
2021-05-13  5:23   ` Heinrich Schuchardt
2021-05-13  7:03     ` AKASHI Takahiro
2021-05-12  4:57 ` [PATCH 4/4] test/py: efi_capsule: add image authentication test AKASHI Takahiro
2021-05-12  5:04 ` [PATCH 0/4] efi_loader: capsule: improve capsule authentication support Heinrich Schuchardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210514045031.GC15502@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox