[PATCH 0/2] RFC: add fdt_add_pubkey tool
François Ozog
francois.ozog at linaro.org
Tue Nov 9 14:16:17 CET 2021
Hi Jan
On Tue, 9 Nov 2021 at 13:58, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> On 09.11.21 13:43, François Ozog wrote:
> > Hi
> >
> > as we are in design discussions, I would promote the idea of not pushing
> > non hardware related things in the DTB that is passed to the kernel.
>
> This was never proposed. The public keys go into the *control* FDTs.
>
> great ;-)
> > Is your use case to allow U-Boot to verify the kernel's signature ?
> > Why not putting it into an environment variable?
>
> This is both about validating OS FIT containers as well as SPL checking
> U-Boot proper before continuing the boot there. The former case can be
> replaced with UEFI logic and likely taking the key from TEE (we do that
> as well in first prototypes), but the latter can't (yet).
>
> >
> > If your use case is on Arm or RISC-V, both environments are working
> > heavily to make https://arm-software.github.io/ebbr/
> > <https://arm-software.github.io/ebbr/> standard available on a large
> > number of boards.
> > This offers UEFI interface and SecureBoot (and later MeasuredBoot)
> > services. For Arm boards just check for SystemReady compliance.
> > In this context, traditional UEFI secure variables are used to deal with
> > certificates and hashes: PK, KEK, db...
> > You can obviously do differently but you will be on your own to extend
> > the chain of trust to IMA, secure containers (rooted down to hRoT) and
> > other security facilities in the Linux side.
> > Could you describe your use case in more details?
>
> doc/uImage.FIT/signature.txt ;)
>
> More concrete: We are currently massaging board/siemens/iot2050 to close
> its static chain of trust between SPL and U-Boot main, using software
> means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot key).
>
> And will the chain of trust be continuous or with a very brief breakage
with this approach?
I other words, can you enroll the TF-A/TEE/U-Boot key so that it can be
trusted by FSBL key?
Jan
>
> >
> > On Tue, 9 Nov 2021 at 11:07, Jan Kiszka <jan.kiszka at siemens.com
> > <mailto:jan.kiszka at siemens.com>> wrote:
> >
> > On 09.11.21 10:37, Roman Kopytin wrote:
> > > Can we have discussion with code lines? For me it is not very
> > clear, because it isn't my code.
> > >
> >
> > Please do not top-post.
> >
> > > -----Original Message-----
> > > From: Jan Kiszka <jan.kiszka at siemens.com
> > <mailto:jan.kiszka at siemens.com>>
> > > Sent: Tuesday, November 9, 2021 12:17 PM
> > > To: Roman Kopytin <Roman.Kopytin at kaspersky.com
> > <mailto:Roman.Kopytin at kaspersky.com>>; u-boot at lists.denx.de
> > <mailto:u-boot at lists.denx.de>; Rasmus Villemoes
> > <rasmus.villemoes at prevas.dk <mailto:rasmus.villemoes at prevas.dk>>
> > > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
> > >
> > > On 08.11.21 16:28, Roman Kopytin wrote:
> > >> In order to reduce the coupling between building the kernel and
> > >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb
> > >> without simultaneously signing a FIT image. That tool doesn't
> > seem to
> > >> exist, so I stole the necessary pieces from mkimage et al and put
> it
> > >> in a single .c file.
> > >>
> > >> I'm still working on the details of my proposed "require just k
> out
> > >> these n required keys" and how it should be implemented, but it
> will
> > >> probably involve teaching this tool a bunch of new options. These
> > >> patches are not necessarily ready for inclusion (unless someone
> else
> > >> finds fdt_add_pubkey useful as is), but I thought I might as well
> > send
> > >> it out for early comments.
> > >
> > > I'd also like to see the usage of this hooked into the build
> process.
> > >
> > > And to my understanding of [1], that approach will provide a
> > feature that permits hooking with the build but would expect the key
> > as dtsi fragment. Can we consolidate the approaches?
> > >
> > > My current vision of a user interface would be a Kconfig option
> > that takes a list of key files to be injected. Maybe make that three
> > lists, one for "required=image", one for "required=conf", and one
> > for optional keys (if that has a use case in practice, no idea).
> > >
> > > Jan
> > >
> > > [1]
> > >
> >
> https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/
> > <
> https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/
> >
> > >
> > > --
> > > Siemens AG, T RDA IOT
> > > Corporate Competence Center Embedded Linux
> > >
> >
> > For what would you like to have code? The kconfig addition?
> >
> > diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> > index d3a12be228..a9ed4d4ec4 100644
> > --- a/common/Kconfig.boot
> > +++ b/common/Kconfig.boot
> > @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR
> >
> > endif # SPL
> >
> > +config FIT_SIGNATURE_PUB_KEYS
> > + string "Public keys to use for FIT image verification"
> > + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE
> > + help
> > + Public keys, or certificate files to extract them from,
> > that shall
> > + be used to verify signed FIT images. The keys will be
> > embedded into
> > + the control device tree of U-Boot.
> > +
> > endif # FIT
> >
> > config LEGACY_IMAGE_FORMAT
> >
> >
> > But note that we are in a design discussion here, and I'm at least
> > reluctant to code up n-versions without having some common idea where
> > things should move.
> >
> > Jan
> >
> > --
> > Siemens AG, T RDA IOT
> > Corporate Competence Center Embedded Linux
> >
> >
> >
> > --
> >
> > François-Frédéric Ozog | /Director Business Development/
> > T: +33.67221.6485
> > francois.ozog at linaro.org <mailto:francois.ozog at linaro.org
> > | Skype: ffozog
> >
> >
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog
More information about the U-Boot
mailing list