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. Wouldn't it be the enough for testing to apply an overlay with the public key using the fdt command? Best regards Heinrich
