On 12/8/20 10:19 AM, Sughosh Ganu wrote:
On Tue, 8 Dec 2020 at 14:32, Heinrich Schuchardt <xypron.g...@gmx.de
<mailto:xypron.g...@gmx.de>> wrote:
On 08.12.20 06:28, Sughosh Ganu wrote:
>
> On Mon, 7 Dec 2020 at 23:28, Heinrich Schuchardt
<xypron.g...@gmx.de <mailto:xypron.g...@gmx.de>
> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@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.g...@gmx.de <mailto:xypron.g...@gmx.de>
<mailto:xypron.g...@gmx.de <mailto:xypron.g...@gmx.de>>
> >> <mailto:xypron.g...@gmx.de <mailto:xypron.g...@gmx.de>
<mailto:xypron.g...@gmx.de <mailto:xypron.g...@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.
