[PATCH 01/14] qemu: arm: Use the generated DTB only when CONGIG_OF_BOARD is defined
Sughosh Ganu
sughosh.ganu at linaro.org
Wed Dec 9 09:26:07 CET 2020
On Wed, 9 Dec 2020 at 12:56, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 12/9/20 6:25 AM, Sughosh Ganu wrote:
> > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.glpk at gmx.de>
> wrote:
> >
> >> On 12/8/20 10:19 AM, Sughosh Ganu wrote:
> >>>
> >>> On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.glpk at gmx.de
> >>> <mailto:xypron.glpk at gmx.de>> wrote:
> >>>
> >>> On 08.12.20 06:28, Sughosh Ganu wrote:
> >>> >
> >>> > On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt
> >>> <xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
> >>> > <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>>>
> wrote:
> >>> >
> >>> > On 07.12.20 13:50, Heinrich Schuchardt wrote:
> >>> > > On 07.12.20 06:15, Sughosh Ganu wrote:
> >>> > >> hello Heinrich,
> >>> > >>
> >>> > >> On Sat, 5 Dec 2020 at 15:01, Heinrich Schuchardt
> >>> > <xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
> >>> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>>
> >>> > >> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>
> >>> <mailto:xypron.glpk at gmx.de <mailto:xypron.glpk at gmx.de>>>> wrote:
> >>> > >>
> >>> > >> On 11/26/20 7:40 PM, Sughosh Ganu wrote:
> >>> > >> > The Qemu platform emulator generates a device tree
> >>> blob and
> >>> > places it
> >>> > >> > at the start of the dram, which is then used by
> >>> u-boot. Use
> >>> > this dtb
> >>> > >> > only if CONFIG_OF_BOARD is defined. This allows
> >> using a
> >>> > different
> >>> > >> > device tree, using the CONFIG_OF_SEPARATE option.
> >>> This dtb
> >>> > is attached
> >>> > >> > to the u-boot binary as a u-boot-fdt.bin file
> >>> > >>
> >>> > >> Dear Sughosh,
> >>> > >>
> >>> > >> thank your for this series which will allow us to
> >> better
> >>> > demonstrate and
> >>> > >> test capsule updates.
> >>> > >>
> >>> > >> I am not sure if the approach that you take at
> >>> device-trees
> >>> > here is the
> >>> > >> right one.
> >>> > >>
> >>> > >> On QEMU the device-tree is generated on the fly by
> the
> >>> QEMU
> >>> > binary
> >>> > >> depending on which devices the user has specified.
> >>> > >>
> >>> > >> Your idea is to replace this device-tree completely
> to
> >> be
> >>> > able to add
> >>> > >> extra elements (the EFI signature list, see patch
> >>> 2/14). Thus a
> >>> > >> device-tree might be loaded that does not match the
> >>> user selected
> >>> > >> devices.
> >>> > >>
> >>> > >> An alternative approach would be to apply all
> >>> additions to the
> >>> > >> device-tree as an FDT overlay (or fixup). This would
> >> allow
> >>> > the dynamic
> >>> > >> parts of the QEMU device-tree still to be passed
> >> through.
> >>> > >>
> >>> > >>
> >>> > >> I will take a look at storing the public key as part of
> >>> the fdt
> >>> > overlay,
> >>> > >> with a runtime fixup. Although, I think the issue that
> you
> >> are
> >>> > pointing
> >>> > >> to would be specific to Qemu and not other platforms.
> But
> >> I do
> >>> > see the
> >>> > >> merit in having the public-key certificate stored as
> part
> >>> of an
> >>> > overlay.
> >>> > >> If I hit any issues while implementing this, I will get
> >>> back to
> >>> > you. Thanks.
> >>> > >>
> >>> > >> -sughosh
> >>> > >
> >>> > > OpenSBI can supply a device-tree to U-Boot. So this would
> >> be an
> >>> > > equivalent case.
> >>> > >
> >>> > > Best regards
> >>> > >
> >>> > > Heinrich
> >>> >
> >>> > <sng_>: "I am unable to think of a simple and elegant way
> to
> >>> generate
> >>> > the overlay dtb, since this would require creation of a
> >>> corresponding
> >>> > dts file, compiling it into a dtb and then using this on
> the
> >>> platform."
> >>> >
> >>> > Jean-Jacques' patch series introduced some of the necessary
> >> code:
> >>> >
> >>> > [PATCH PATCH v6 00/13] Add support for applications of
> >>> overlays in SPL
> >>> >
> https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
> >>> <https://lists.denx.de/pipermail/u-boot/2019-October/387653.html>
> >>> >
> >>> <
> https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
> >>> <https://lists.denx.de/pipermail/u-boot/2019-October/387653.html
> >>
> >>> >
> >>>
> >>
> https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both
> >>> <
> >>
> https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both
> >>>
> >>> >
> >>> <
> >>
> https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both
> >> <
> >>
> https://patchwork.ozlabs.org/project/uboot/list/?series=137810&state=%2A&archive=both
> >>>>
> >>> >
> >>> > CONFIG_OF_OVERLAY_LIST is used to specify the overlays to
> be
> >>> compiled.
> >>> > You will have to remove the
> CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY
> >> and
> >>> > CONFIG_SPL_LOAD_FIT dependency.
> >>> >
> >>> >
> >>> > What i meant was that the process to generate the fdt overlay
> on
> >> the
> >>> > host, embed it with the public-key certificate is more
> cumbersome
> >>> than
> >>> > the current solution. So, for comparing the embedding the
> pub-key
> >>> cert
> >>> > in the fdt overlay, as against the platform dtb
> >>> >
> >>> > Embedding the certificate in the overlay
> >>> > 1) Generate a skeleton overlay dts file
> >>> > 2) Convert it to a dtb
> >>> > 3) Run it through the mkeficapsule utility to embed the pub-key
> >>> > certificate in the overlay(dtb)
> >>> > 4) Store the overlay dtb on some nv storage on the platform(ESP
> >>> partition?)
> >>> > 5) Load the overlay and apply it to the platform's dtb
> >>> > 6) Retrieve the certificate from the dtb at the time of capsule
> >>> > authentication
> >>> >
> >>> > Embedding the certificate in the platform's dtb
> >>> > 1) Run the platform's dtb through the mkeficapsule utility to
> >> embed
> >>> > the pub-key certificate
> >>> > 2) Boot the platform with the platform's dtb
> >>> > 3) Retrieve the certificate from the dtb at the time of capsule
> >>> > authentication
> >>> >
> >>> > You had mentioned OpenSBI passing the dtb to u-boot. Does the
> >> OpenSBI
> >>> > generate the device tree for the platform on the fly even for
> >>> non-qemu
> >>> > platforms. If it does not, the dtb that OpenSBI uses can be run
> >>> through
> >>> > the mkeficapsule utility to embed the certificate.
> >>>
> >>> OpenSBI applies fix-ups before passing the device-tree. The
> prototype
> >>> device-tree can either be built into OpenSBI or can be passed
> from an
> >>> earlier firmware stage.
> >>>
> >>>
> >>> So, if qemu if the only platform where the device tree is generated on
> >>> the fly, and passed along, based on the comparison that i have stated
> >>> above for the two scenarios(overlay vs platform dtb), I feel that using
> >>> the platform's dtb and embedding the certificate is more easier to use
> >>> than using the overlay.
> >>>
> >>> Even on the qemu platform, I retrieved the dtb from the platform, for
> >>> the given set of devices and interfaces used, and then ran the dtb
> >>> through the mkeficapsule utility.
> >>>
> >>> -sughosh
> >>
> >> As I understand the whole series is not about productive firmware
> >> updates for QEMU but about a demonstration how it could be used and
> >> allowing testing.
> >>
> >
> > True, but the process of embedding the public key certificate into the
> > platform's dtb for use in capsule authentication can be common for all
> > platforms. If you are fine, we can keep this patch to be used on other
> > non-qemu platforms, while i work on the overlay method for qemu. Will you
> > be fine with this approach.
> >
> > -sughosh
> >
>
> This patch only changes board/emulation/qemu-arm/qemu-arm.c. Hence "keep
> this patch to be used on other non-qemu platforms" is not applicable to
> this specific patch.
>
Sorry, i did not mean this patch, but patch 02/14, "mkeficapsule: Add
support for embedding public key in a dtb". I meant that that patch can be
used for other non-qemu platforms.
-sughosh
More information about the U-Boot
mailing list