On 15.12.20 12:10, Sughosh Ganu wrote: > > On Wed, 9 Dec 2020 at 03:24, Heinrich Schuchardt <xypron.g...@gmx.de > <mailto:xypron.g...@gmx.de>> wrote: > > 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> > > <mailto: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>> > > > <mailto: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>>> > > > >> <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 <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://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>> > > > > > > > <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. > > Wouldn't it be the enough for testing to apply an overlay with the > public key using the fdt command? > > > Is there a way I can build qemu such that the device-tree that is > generated is with the __symbols__ node. Without this node, I am unable > to apply the fdt overlay on the base platform devicetree.
According to https://www.kernel.org/doc/Documentation/devicetree/overlay-notes.txt __symbols__ is only needed if you refer to phandles in the overlay. When using paths instead __symbols__ is not required. I have not tested if this holds true for U-Boot too. Best regards Heinrich > > -sughosh
